Wix per user files,Can you not use the registry? - wix

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.

Related

Specify directories to not be removed on uninstall

I have a WiX installer for an app that can generate two folders while running. I'd like these two folders to not be removed on uninstall however. I'm using RemoveFolderEx to remove the entire install directory, but wasn't sure if there was a way to exclude folders from being removed.
I've tried using a Custom Action with a PowerShell script to move the folders out of the directory, but this solution would rely on the script being somewhere outside of the install directory in order to be run before the folders are removed, and doing this unfortunately gets rid of the installer's portability.
Have you tried setting the msidbComponentAttributesPermanent attribute on the required Component(s) to make them permanent?
https://learn.microsoft.com/en-us/windows/win32/msi/component-table

Proper way of installing per-user files during a per-machine installation

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.

How to copy files and folders in ISWIX?

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?

Wix bundle uninstall package with custom install location

I have a Wix bundle which allows users to customize installation directory and passes the value to the package during installation. This is implemented using the approach described in this answer: How do I pass a default 'install location' to the RtfLicense bootstrapper?
If the user does not change install directory after running bundle and uninstalling it all files are deleted as expected. If the user does select another installation directory and runs bundle and uninstalls the app the files are not deleted. I guess this happens because the bundle passes default directory but it obviously isn't there. What's more the shortcut that's created during installation is deleted as the shortcut location does not depend on the installation directory.
How can I solve this issue?
The "install location" is not saved by the bundle. The packages have to save anything they need upon installation and read it back during other operations. For an MsiPackage, this is typically done using the "Remember Property" pattern. Directory paths are manipulated as properties so save any directory paths you need.

Upgrading doesn't update VirtualStore file

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.