I have created a program that uses an accdb file. I have also created a setup project for deployment of said program. However, I am having difficulties with the accdb file being ready only in Microsoft Vista.
First I had the accdb file installed into the DataDirectory, but realized that if you need changes made to files the Program Files location is not the place to install files.
SO I attempted to install into the ProgramData directory but the accdb file is still read only.
I then attempted to install into the users directory, but can not get the connection string in the app.config file to be correct.
So ultimately, my questions are:
1. Where do I need to install an accdb file so that it is not read only?
2. How do I configure that directory in the FileSystem within VS2010?
3. What should the connection string in the app.config look like?
I would like this to work in XP, Vista, and W7 if possible. It would be okay to create multiple setup projects if need be for it to work across multiple OS.
You should install the db file to the LocalAppDataFolder.
It seems you've tried this...
But can not get the connection string in the app.config file to be correct.
Rather than set the connection string at design time you should set the string at runtime
From ErikEJ's answer to a similar question
string fileName = System.IO.Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
"SqlCe35AddinStore.sdf");
string connString = string.Format("Data Source={0};", fileName);
Related
I have a Visual Studio Setup project which includes a .SQL file from my project which should always overwrite the existing file if I run the installer on the same machine to update to a new version. The problem is that doesn't always seem to happen. Under File System > Application Folder > File Installation Properties, which property would tell the installer to always overwrite the existing .SQL file on an install?
The upgrade is an install of the new files on top of the older files, during which file overwrite rules are followed. The rule for data files is that they will not be overwritten if they've been updated since they were installed. If you've installed a database that's now full of customer data it's usually a bad idea to just replace it with a new empty database:
https://learn.microsoft.com/en-us/windows/desktop/msi/neither-file-has-a-version
Among the ways to solve your problem are:
Update the existing file with the new data using a custom action.
Avoid the problem in the first place by having the installed file copied to a location where it can be used, updated etc by the application. The original can then be overwritten by the upgrade, and the application detect that there is a new one to use, that it copies to replace the previous copy. It maybe too late for this.
Have the application make the creation date and modify date of the file have identical values so that the upgrade will think it's not been updated.
Install the new file to a different location (and use 1. from now on). The older file will be removed by the upgrade.
Edit the MSI file (with a tool like Orca) to move the location of RemovePreviousVersions (in the InstallExecuteSequence) so that it is immediately after InstallInitialize. This will completely remove all of the old files before installing the new ones, so it won't help if you have that database full of customer data mentioned in the opening paragraph.
I am new to Unity3d development. I have created two versions of a 3D puzzle app, one for Mac and the other for Windows. Mac applications are created with the package contents contained within it. The Windows application is created with the exe file and a separate data folder with the same name as the exe file + suffix _Data. I want to create a single exe file to distribute on Amazon and other downloadable platforms. The problem I'm having is finding something where the data folder and the exe file have to be located at the same level.
I'm used to Apple devices but recently purchased a Windows laptop for testing.
I could not find anything in the Unity3D documentation on how to do this. The documentation talks about how to distribute the application to the Windows Store, something I don't plan to do. The only thing I could find on their forum was one question that was asked in 2011.
One of the suggested solutions, Enigma Virtual Box, I could not get to work because Unity3D requires that the exe file and the data folder be at the same level. I have also tried the trial for Smart Packer Pro but I need a dll file as a starting point which I could not find in my Unity3D project folder.
All of the information I'm finding related to Windows packaging into a single exe file are at least five years old. None of them relate to packaging Unity3D applications. I have also searched microsoft.com and windows.com but could not find anything there.
UPDATE 5/12/2016 14:15
I installed Inno Setup and attempted to create a script for my application. It copied the exe file but created an empty data folder instead of copying the data folder I need to run the exe file. I checked to make sure that the folder name was correct in the script.
; -- myapplication.iss --
; Demonstrates copying 3 files and creating an icon.
; SEE THE DOCUMENTATION FOR DETAILS ON CREATING .ISS SCRIPT FILES!
[Setup]
AppName=myapplication
AppVersion=1.0
DefaultDirName={pf}\myapplication
DefaultGroupName=myapplication
UninstallDisplayIcon={app}\myapplication.exe
Compression=lzma2
SolidCompression=yes
OutputDir=userdocs:Inno Setup Examples Output
[Files]
Source: "myapplication.exe"; DestDir: "{app}"
[Dirs]
Name: "{app}\myapplication_Data";
Packing a Unity3D application is not not possible without 3rd party software.
a bit more recent url (2014) suggests using smart packer, this however is a tool I personally never used before.
I tend to use inno setup as it seems a bit more professional, it eases up moving files, creating links (short-cuts) and uninstalling quite a bit as well. Simply said, this allows you to extract the exe and _data folder to the same folder, and create a shortcut to the exe.
Follow up on edit
I installed Inno Setup and attempted to create a script for my application. It copied the exe file but created an empty data folder instead of copying the data folder I need to run the exe file. I checked to make sure that the folder name was correct in the script.
After selecting the main exe file during the application files part of the setup wizard, you can add a folder. Here you can select yourgame_data folder to be included in the installer. This however does require an additional step. After adding the folder, you need to set the destination subfolder to yourgame_data for it to be able to properly create the subdirectories. You can refer to this picture guide for more information. I included the relevant step(s) below.
We have a couple of dlls we like to install using an msi.
In our test environment, we are using regasm -codebase to register the dlls.
As I understand from googling, this is accompliched in an msi project by setting the register property to vsdraCOM.
The problem is that when we run the installer and checks the registry, the codebase path is set to the path the file were in when building the msi.
I'm going to expand on Hans' answer and that link info, and it may be more than a comment can hold.
That reg file will contain the path to the file and the link article recommends using [TARGETDIR], which is basically wrong if the file is not being installed to the application folder. The path to your file should be written as [#file-key] in the reg file that you import. In a VS setup project the file-key will be (just an example) something like _B049230C37DE4B6787C578DCEE30252A. Open your MSI file with Orca, go to the File Table and use the file key in the File column that corresponds to your file name.
That comes from here:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
the 7th bullet point. It resolves to the file path wherever it is installed to.
The other thing that can be done is to let Visual Studio do its incorrect thing, then go to the Registry table with Orca, find the path and put that [#file key] in it such as [#_B049230C37DE4B6787C578DCEE30252A] and people sometimes do those kinds of updates with a post build script to update the MSI.
None of these are great, but they should work and get you out of using the GAC. VS setup projects really should be using that [#file key] syntax, and it's just a silly bug I assume.
Speaking as someone who's made a full time living writing installs for 18 years, my first suggestion would be to switch to Windows Installer XML. If you insist on using .VDPROJ, I would suggest reading: Redemption of Visual Studio Deployment Projects.
The concept is you use Windows Installer XML to create a merge module and then consume that merge module with .VDPROJ. In Wix, you use Heat to harvest the DLL. It will extract the COM / Regasm metadata and author it as Registry table entries. This provides a nice clean encapsulation using authoring best practices and avoids the need to do any post build hacking of the built MSI database.
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
Context : Windows 7, VS 2010, Tortoise SVN , and VisualSVN (all up to date)
We have some problems with our web.config files and .csproj : in these files there is informations common to the whole project (like connection string, configuration element) and informations depending on the machine (mostly file path).
So the problem is, each time I commit my web.config, my colleague has to go back to his file and change the file paths.
Did you find any way to handle it ? I tried to remove these from source control but it's kind of a problem (each time someone add a file to the project we have to add it manually, or a configuration key).
Thanks
One way we've handled file paths in the web.config is through the use of symbolic links.
i.e. in the commited web.config have the files paths point to e.g. C:\website then on each developers machine run the following command:
mklink /d C:\Website c:\path\to\develper\specific\checkout
Thus no-one should need to re-edit the paths to point to their workspace.
We've not had problems with our .csproj files - they don't have machine specific config in them.
We did however have similar issues with app.config settings. Again solved by either having each developer store files in a set location or having a symbolic link from the set location to their location.
For connection strings, we've either got them all set to localhost or set them to localdatabase and have a host entry on each developers machine. This will only work if each developer connects to the same database name but on a different server. If you're connecting to the same database server but different databases, you'll need a different tactic.