I am developing an installer using Wix. I am using the ISWIX add in. I want to copy some folders in installation directory during installation. And these files and folders must be deleted after successfully uninstalled. And I also need to copy a library to the system folder of the PC and that should also be deleted during uninstallation. For this, do I need to have admin access? Is my installer can have launch condition like to check if the user is Admin or not?
Though it contains multiple questions but all the questions are correlated.
If you want to install files into the "C:\Program Files" or "C:\Windows\system32" directory you'll need to run the installer with administrator/elevated privileges. MSI has a built-in property that gets populated when the user as elevated privileges: "Privileged". You can add a LaunchConditions table entry with the condition "Privileged" - https://msdn.microsoft.com/en-us/library/aa370852%28v=vs.85%29.aspx
I'd also give this post a read - How do I get WiX installer to request administrative privileges?
Related
I have a per-machine WiX installer (InstallScope="perMachine" InstallPrivileges="elevated") and I need to create a folder and copy a few files to the Documents folder of each user running the application. At the moment I install the files to a personal folder of the current user, but that's wrong and I get the ICE91 verification warning:
ICE91: The file 'SomeFile' will be installed to the per user directory 'SomeDir'
that doesn't vary based on ALLUSERS value. This file won't be copied to each
user's profile even if a per machine installation is desired.
I want the files to be automatically copied to the Documents folder of each user. Could someone post the step-by-step instructions how to do that?
UPDATE: I will be on holiday until September, during that time I will not be able to respond to any comments.
Windows Installer will do this - it's what advertised shortcuts will do. If you install a file to a user specific folder location and a different user logs on, then that file will be missing for that user and repair mechanism of the advertised shortcut repair will install it from the original MSI file. In your case the PersonalFolder property is the user's Documents folder.
To arrange this, the file must be the keypath of a component, and that component must be in a feature with an advertised shortcut. When the shortcut is used the component and containing feature are checked for "self healing" and the missing file installed. This works for users that don't yet exist. Older Office installers once did this to install user-specific items such as templates.
The MSI must obviously be available for this to work, and there is no mechanism to remove the files at uninstall time.
An alternative (or if there are no advertised shortcuts) is to add code to the app that calls MsiProvideComponment (or equivalent p/invoke) passing the ProductCode, feature name, Component id (of that documents file) and use INSTALLMODE_DEFAULT, which will install the file if it's missing as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370356(v=vs.85).aspx
and it will be missing and therefore will be installed for a user who has not run the app before.
Why would you want to do this this way? What if there are 10000 (just for example) users on the machine? You want to copy the files to all 10000 documents folders taking up potentially GBs of space (depending on the size if the files copied)? If these are configuration options needed by your app, the app itself should create default files in the user's documents location on the first run if they are not present otherwise load the settings from these files. You should not put the default files there for every single user on the machine at install time.
This approach also fails for new users added after you install. How will they get the files in their documents folder? Do they have to reinstall the product?
Consider a per machine install of per user installers with shortcuts that interested users could launch. For example, templates.msi, examples.msi.
I am about to create a MSI package.
During the installation (launched e.g. via double-click on the MSI) some files contained in the MSI are deposited deeper under c:\ProgramData (resp. the CommonAppDataFolder), e.g. c:\ProgramData\myCompany\myApplication.
Later when the installed application is run by the user the application may need to modify these file.
The problem is that neither the running application nor the user e.g. via Windows Explorer has the right to modify any files under c:\ProgramData\myCompany\myApplication created during installation.
The files do not have a readonly attribute set.
The strange thing for me now is: If I install the MSI via msiexec /q /i then I have write permissions on these files.
My MSI is created with WiX, my os is Win 7, the user is member of the administrator group.
Can anyone tell me why that is so, and how I can gain write permissions to these files w/o having to use /q /i?
Thanks
Jan
EDIT 2014-03-24: Damned. I missed to specify the InstallPrivileges attribute on my element, I just didn't know about it.
Setting it to "limited" does not show up a UAC prompt when installing to ProgramData! And now the user / my application is allowed to overwrite files in the destination folder :)
I don't know why that behavior would be different regarding access to that folder unless you have a custom action that does something that is only in the UI sequence. That's the only functional difference I can think of - the UI sequence is suppressed in a silent install.
However the common app data folder is not normally writeable to limited users. I'm not sure how much you know about UAC, but it doesn't matter if the user running the program is an admin or not because by default admins run with limited privileges. If the app needs admin privilege to run then it needs building with an elevation manifest so it asks for elevation to admin privilege. Either that or run it as administrator from a shortcut.
Windows access control is extremely complicated to deal with. In every version of Windows there is something new and changed to deal with, and it looks like the default write access in ProgramData now includes some sort of special ACL / DACL. If this is indeed the problem you can apply new permissions there and open up for regular users to write. Please note that I am not quite aware of exactly what newer versions of Windows apply as default. The tool I generally use to set permissioning is subinacl.exe. A real handful of a tool with a command line that can scare the most experienced system administrators. Some command line samples are here. You can also use the LockPermissions table in MSI, but somehow there are some issues with how these permissions are applied to the file system object. subinacl.exe is more complex, and more capable.
More on file and folder permissioning:
http://technet.microsoft.com/en-us/library/bb727008.aspx
http://support.microsoft.com/kb/308419
With regards to where you should put different types of files on the system, please check this thread.
I haven an installer which must run with elevated admin rights if UAC is enabled. This works fine. When I upgrade the app (using the MajorUpgrade element) the app gets uninstalled and reinstalled correcly.
During runtime the app attempts to change some files in the program files folder which places copies them items in the users virtualstore. These do not get removed during uninstall.
During the upgrade/reinstall process, is there a correct way to delete the application file copies, for all users, in the VirtualStore?
Files placed into a virtual store are, by definition of who wrote them and when, per-user data files. Such files typically should not be removed during uninstallation. If the files in question are not actually per-user data files, the application that caused them to be written should be fixed to write to a proper location, update them in a controlled fashion, or even not write them at all.
When uninstalling my app, I'd like to configure the WiX setup to remove directories and like user settings and user data I want add a dialog with two check boxes and optionally remove all the files that were added. It looks like the uninstaller removes only the directories and files that were originally installed from the MSI file .
In other words, I want to give user a chance to Delete his data with a dialog while uninstall is called ?
Is this possible through WiX without resorting to custom actions? Any help would be appreciated.
To do this without using custom actions, see the WiX documentation regarding the RemoveFile and RemoveFolder elements. You can use these to remove files and folders on uninstallation. RemoveFolder will only work if the folder is empty.
Note that if the files are located in the user's application data directory, you will only be able to do this for the user that is uninstalling the application. You cannot easily do it for all users.
So I have files that are saved per user under the "PersonalFolder" Wix folder.
It seems that to have these per user files, I have to use a RegistryKey as the KeyPath.
Several of these files are per user configuration files that we do not want to overwrite during install, so I'm using the Permenent flag. Well now my users want to do a "clean install" so they delete the configuration files, but the registry keys persist. So now when they reinstall the files are missing.
Is there anything I can do in the installer for this?
As far as I understand, you are worried about the user deleting some of the files but not the registry keys before trying to install again. To account for this, your installer at the very beginning should check if anything is left over from the previous installation.
Check if the registry keys or directories exist
If they do, run a batch file to delete them before starting the actual installation.
Do the clean installation.
You can use CustomAction to run a batch file if some things are left over from the previous installation. Schedule the CustomAction in InstallExecuteSequence before the InstallFinalize.