I have to find a suitable location to deploy my SDF (database) file.
The file must be the same to all users
Windows applications can't write to the ProgramFiles folder.
One user can't access other user's AppData folder
A good choice would be %ProgramData%
In Visual Studio Setup Project File System view, when I right click the output folders I don't have the %ProgramData% option
How to write to that folder?
Check this out:
Specifying c:\ProgramData folder in Setup project?
Winforms Deployment
string path = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
CommonApplicationData is C:\ProgramData on Windows > Vista, and something like C:\Documents and Settings\All Users on XP.
Actually this question is a duplicate. Here is the real way tell VDPROJ to deploy to that location:
Writing to AppData from a Setup & Deployment Project
But that will leave another problem: Standard Users won't have write privs to that directory. You'll either have to write a custom action to open it up or you'll have to use a better MSI authoring tool such as Windows Installer XML (open source) or InstallShield 2010LE ( free ) that has proper support for defining resource permissions.
Related
I've developed an Outlook addin that perfectly works with my outlook. I used our organizational code signing cert and used ClickOnce. Now I want to deploy it on a small group of machines (piloting). I followed this to create an MSI. The problem here is it copies all the files to C:\ with I double click on the setup.msi. But when I run it as an admin, it copies the files in the right location. Below is what I get from the msi log file.
MSI (s) (84:FC) [13:43:15:553]: Ignoring disallowed property TARGETDIR
MSI (s) (84:FC) [13:43:15:964]: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'C:\'.
What am I doing wrong?
Looks like you need to change the target folder of your installer. Most probably you chose a folder which requires admin privileges for writing.
You may find the Deploy an Office solution by using Windows Installer article helpful.
With Visual Studio Setup Projects the main reason for this is that the installing user does not have admin privileges, as you seem to have discovered. These VS setup projects switch to a per-user non-elevated install when the user is not privileged. Among other things, this means that the install can't create files and folders in restricted locations (the Program Files folders and others) so the install gives you a separate isolated install in C:. The ALLUSERS value in a VS setup project is 2, and as the documentation here says:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367559(v=vs.85).aspx
you can get a per-user non-elevated install if the user is not privileged. Windows won't let limited users write to restricted locations just because it's an install.
In a visual studio setup project, is there a way I can enumerate the logical drives on the target machine and set a path on a drive on which windows is not installed as the value of the property "DefaultLocation" for the Application Folder instead of the usual [ProgramFilesFolder][Manufacturer]\[ProductName] ? Or is there a way I can force the users to select the installation path on a drive other than the windows drive, without which the installation should not proceed?
Thanks in advance.
No, not in a Visual Studio setup project. There is no support for running any code during the UI sequence, and so there is no way to check the user's input if offered a dialog to choose the location.
Is there a problem you're trying to solve and this is the solution you've chosen? It's not clear why the standard location in Program Files is unacceptable.
If you were willing to force the issue you could write a launch program that would find the drive and then install the MSI (omitting the destination folder dialog) with a command line that includes TARGETDIR=[folder path for install]
I have created a folder under Windows\system32 with a config file in it. For some reason when I browse to that folder with the Visual Studio Open folder dialog the folder does not exist. You can certainly navigate to it via explorer or any other way you want to. Is there anything special about this location that causes this? BTW: I am on Windows Server 2008 R2 and using VS2010.
TIA!
#Hans: I'm guessing you are running this on a 64-bit version of Windows. Which uses file system redirection for 32-bit processes, like Visual Studio. You'll end up looking in c:\windows\syswow64 instead. Do not create folders in c:\windows\system32. The c:\windows directory is reserved for Windows.
I created Visual Studio 2005 Setup project for my application. Windows Installer during installation put one xml file into AppData/myCustomFolder. I used File System Editor and added special folder - user's app data folder, then included that xml there.
When I uninstall application from Control Panel folder from Program Files is deleted, but also my xml file from AppData is deleted too. I need to leave this xml file in the AppData always, even when user re-install application.
How I could do it?
Set the Permanent property to True
Permanent Property
Using Windows Installer (targeting XP and Vista), is there a best practice for installing demo projects and files with your application?
From experience installing on Vista/XP I would recommend...
1, Install the source code/project/solution files into the 'Users' directory for Vista. That way when the user opens up the demo and compiles they have write access for generating the output files. If you put the files into the 'Program Files' directory under Vista you do not have write access and so the compile will just fail.
2, Add a shortcut to the solution to either the desktop or the start menu so that the user can then get access to it without having to know the exact location. Under Vista/XP when you install into the 'Users'/'Documents and Settings' directory it is not easy to find the installed files because they are placed inside a directory that is not shown unless you select 'Show Hidden Files' in file explorer.
3, I would recommend you sign the installer using your publisher certificate so that when the user gets a UAC dialog on Vista they can see the name of the publiser and be more likely to continue with the process.
4, At the moment the split between Visual Studio 2005/2008 is about 50%/50% and so make sure you provide both versions of the project/solutions files. Alternatively just supply the VS2005 files and let the user upgrade using the wizard in VS2008.