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.
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 have been working on a group of installers over a few years and am starting to run into problems with the amount of disk space that is used when the package is installed. The installer works great but installs/copies a few redundant sets of files in the process. I do admit that that some of my assumptions may not be correct, but this is based on my best understanding of the MSI processes. Let me explain ...
1.) Self-extractor file - The compressed MSI, associated bootstrapper packages and setup.exe file is downloaded by the user creating the 1st set of redundant files. Not a big deal, because this can easily be deleted after install.
2.) Extracted Files folder - After running the EXE the files are extracted to a static location from which the bootstrapper is launched. This now has created the 2nd set of uncompressed redundant files on the hard drive. These files are useful to be able to re-install of debug installs as needed, but may not be needed after install is completed. It has never been clear to me whether patched installs depend on these files or only the files stored in C:\Windows\Installer. Assuming the latter.
3.) TEMP folder - As the installer runs from the extracted location it copies files to the TEMP folder and runs the files from that location. This creates the 3rd set of redundant files. Again it is not really clear whether these files can be removed after install or if there is an automated process that MSI does to make this happen.
4.) Windows\Installer folder - If I understand correctly this is where some sort of stripped out file set is stored that manages the ability to patch. So this is the 4th set of files that may or may not be smaller than the some of the extracted sets of files. This one needs to not be deleted so patching will work.
5.) Install folders - Final install location for the software. This is now the 5th set of files that are installed to my computer and of course is the desired set of files.
I would like to better understand the process so I can improve the way that I distribute our software so that I can avoid or resolve some of the issues I am seeing with needing many different sets of files. I am very open to any best practice that might be out there that I have not observed. Thanks for your help.
I can't speak to the exact bootstrapper you are using but you might investigate using the Burn bootstrapper in WiX v3.8 to create a Bundle of Packages. I know the details of how that works and it will reduce the number of copies from what you are experiencing now.
Self-extractor file - a Bundle this can either contain all the files in the single executable or download them from the internet on an as needed basis. In the latter case, the self-extractor file could be ~250K.
Of course, this can be deleted as soon as the install is complete.
Package Cache - the Burn engine carefully downloads files to the TEMP location, verifies their integrity and moves them into the well-known Package Cache without creating any other duplicates. The Package Cache is important because the Windows Installer can get into situations where it requires the original source files. If that location is in a TEMP location that was deleted the user will have a very hard time providing the original source files. The Package Cache also improves the reliability of the installs. Finally, it is a cache so it *can * be removed (although not recommended) and the next execution of the Bundle will put the necessary packages back in the cache.
Also, this content is the original source media and can still be compressed.
Windows\Installer folder - the Windows Installer will cache the .msi file. If you do not embed the cabinet files in the .msi file (which is unnecessary when using a Bundle since the Bundle can embed all the files if desired) then the cached .msi file should be less than a couple megabytes.
Install Folders - this is your application, you probably need these files here. :)
So, in the end using the Burn engine you should end up with one copy uncompressed (the app itself), one copy compressed (the package cache), and a tiny bit of overhead for the .msi file cached.
I have a Wix installer which is designed to install (uninstall) a Windows service and another .exe file. When I uninstall the software using this installer, and enabling extra log, I see some error messages about unable to remove my installation folder, although it is indeed empty. The first message that appears on the log is like this:
DEBUG: Error 2911: Could not remove the folder MY_INSTALLATION_FOLDER.
The following errors are all about the same problem. My first guess is of course that there are some resources that were being used during the uninstallation. However, like I mentioned, all components in this folder were indeed removed and this is an empty folder by now. Also, this error is the first error in the log, meaning there was no error prior to removing this folder. For example, from the log I can see a series of FileRemove actions were taken right prior to the folder removal and they all succeeded. So it's gotta be that this folder itself was being used. But I really can't figure out why and what is holding this folder. By the way the software was indeed uninstalled since the final product removal returns 0 and every thing related to our software was removed (Windows service list, shortcuts, registries...) excepted this empty folder. It is not crucial but we definitely don't want to hear from our customer asking about this kind of error anyway(they are using auto-installation and the log is by default enabled and checked)
Please help. Thanks!
Possible causes:
Other process is locking that folder. Use Unlocker to
verify if that's the case.
Some folders have restricted permissions
by Windows (e.g. C:\Windows\system32). Generally, you should avoid creating files under Windows own folders (unless it's required, I.e.: your'e installing a device driver).
Did you properly set folder permissions?
My application runs as a Windows service. During normal execution, some data files are generated in a "data" directory that I create with my WIX install. During an upgrade, I would like to move/migrate those files to the same data dir in the upgraded installation. However, I am running into issues. I am using the "MajorUpgrade" tag as follows:
I tried scheduling later in the process(afterInstallFinalize), but that runs into issues with the service having locks on files during the upgrade. I have combed Stack Overflow and google, and it seems that no one else is describing my scenario. Others have default *.ini files, that the user can potentially edit. However, in my case, it should always be safe to migrate the files, as there are no defaults. They are simply data files that need to be migrated.
I thought I could possibly do this via a custom action, but was not sure how to do it.
Any suggestions would be very much appreciated.
Edit: Apparently using "afterInstallFinalize" works fine for me, i.e. data files are migrated, as long as the user does not change the path during upgrade. If I change the path during upgrade, I get warnings about files being locked, and asking to stop the app using the files. However, it ends up not migrating the files in that case.
Ultimately, I solved my own issue by simply overriding the default dialog behavior, and changing the flow such that on upgrade, I skip over the "InstallDirDlg".