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.
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.
MSI (created from WIX)- Uninstall application is not removing the root installation folder.
1) I have installed the MSI (example: selected installation root location: C:/MSI_test/ and installed with AppName. And final location is C:/MSI_test/AppName/) and part of the installation copied MSI into my installation location (for repair purpose from uninstall shortcut Key. When I click the uninstall shortcut it points to the MSI in my installed directory and opens a dialog with Repair or Remove option)
2) If the user tries to uninstall this application from the uninstall shortcut, it removes all the installed files and folders but not removing the root installation location (i.e. C:/MSI_test/AppName/).
Below is the code having in my uninstall.bat file (which is called during uninstall shortcut)
cmd.exe /c start "" "C:\MSI_test\AppName\Config\App.msi"
exit;
3) If I have MSI in different location (i.e. in C:/testing) and trying to uninstall the application, it removes everything (i.e. installed files and folders including root installation location)
4) Is this a problem to delete the root folder if we are trying to uninstall from the above step-2 to delete the root installation folder?
The problem you're having is likely to be that your uninstall is holding the folder open. I've solved this problem previously by creating an exe that does the uninstall and copying it to the Temp folder andf running the uninstall program from there, and people generally clean up the temp folder anyway.
This might be a better way of doing it too:
http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-uninstall-shortcut-and-pass-all-the/
What you're seeing is the result of a lock being placed on that folder or its contents, likely as a result of the batch file itself executing (which sets the working directory of the command interpreter running it to the folder it is in, and places a read lock on the folder).
That said, I'm unsure why you're making a copy of the MSI in the application folder anyway, as the Windows Installer will make a copy itself and place it in %windir%\Installer. When you kick off your uninstall from the shortcut, the installer reads the product code from the MSI you provided it and then goes back to the cached copy anyway.
Ideally, you should do away with the batch file and place a direct shortcut to msiexec.exe /i {product-code} - this will kick off the installation/maintenance UI for your product if it is installed. If you must have a batch file, you will need to place it outside your application's installation root.
I have per user installation.
Application will be installed to user's AppData directory.
There is following warning during build of wxs file:
warning LGHT1076 : ICE91: The file 'app.exe' will be installed to the per user directory 'INSTALLDIR' 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.
What does it mean that file won't be copied to user's profile?
As I can see my application is isntalled without any problems. File is installed to user's AppData directory.
Normally, when you install a file to a user profile location and another user uses the app in a per machine install, you want all the files there. Otherwise you have an app that works for the installing user (because the file is there in the user profile folder) but it won't work for other users because the file is missing. If the MSI file was built "correctly", another user would log on, use a shortcut (for example) and Windows would notice the missing file and install it, therefore every user account (even those that are not yet created) will get a copy of the file in their user profile folder. If you're doing a per machine install and you want every user (not just you!) to get a copy of the file you should fix it.
CE91 posts a warning if a file, .ini file, or shortcut file is
installed into a per-user only directory. These warnings are harmless
if the package is only used for installation in the per-user
installation context and never used for per-machine installations.
You may wanna take a look into the docs.
If you want to suppress that warning msg take a look into this SO
i have created an MSi installer. when i install this installer it also installs a visual studio project which is actually a tutorial project. When user runs this project it generates Bin and Obj folders. when i uninstall the install it does not delete all the those Bin and Obj folder which are generated after the installation.
Can you provide me some example how to use RemoveFolder tag in Wix to remove those two folders and the files inside them recursively.
Thanks
RemoveFile will only remove files that are installed by this msi.
To remove entire folder you have to use util:RemoveFolderEx. To use it you have to:
- Store [TARGETDIR] in registry on install;
- Retrieve it on any actions except on install and store in local variable (using RegsitrySearch)
- Add util:RemoveFolderEx action to your main component and pass your stored path variable to the Property attribute.
If you need an example I could write it for you.
I have a problem which is related to the execution of CopyFile on change/repair when using WIX to make a msi setup.
I have a feature which has a component which copies/moves a file from the source folder to a folder already present somwhere inside a users system. It is not the folder of my application. I am only moving this file and not installing it to the the target. This feature works fine if I install it using a complete setup. But when on initial install I chose not to install this feature and then try to install it during a " change " all other custom actions/components inside the feature are executed/installed except for the CopyFile component. This is critical to my setup and if it does not get copied my setup will fail.
Just wondering if anyone found a solution to a similar problem or ever came across a similar issue?
The component which contains the CopyFile operation is configured incorrectly. It should have an actual file or registry entry as a key path.
Although Windows Installer uses components to manage resources, the component key path is main factor which decides if the component is installed or not.
So a component without a resource as a key path will never be installed and the CopyFile operation it contains will never be executed.