I have an Air app that was published as a native installer. If the user uninstalls the program it doesn't remove the folder that it was installed in. Then when the user tries to install again, it will throw an error saying that folder already exists.
ie if the program is C:/program files/my app/{contents here}
it removes the {contents here} but leaves the /my app directory.
Is there a way to make sure that folder is removed at uninstall time?
I don't think there's a way of forcing the uninstaller to delete the folder, but the reason it's not deleted is because it contains files that were not put there by the original installation. If, for exemple, you saved user profiles in your installation folder hierarchy, it won't be deleted.
You can't make sure the user won't put any files there, but at least you can avoid writing any file/folder in your installation folder from your app. Instead, use application storage folder (File.applicationStorageDirectory). You can also easily create new folders there with File.applicationStorageDirectory.resolvePath("exemple");
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 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.
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.