It seems that the upgrading installs don't replace files with new versions, but they actually uninstall the old setup package and install the new setup package. Lets imagine that I've installed my application and it generated some files in the install directory. Then the user gets a new version of the product and launches the install package. The package deletes the old version of the product (because the new setup package has "remove previous versions" set to true, higher version number and different product code). The files that were created by application, but not by the package, are not deleted, and this is good. But the user can install the new version to a different location, and then the application won't find the old application files. How do deal with it? Write some custom actions and conditions that skip the folder selecting screen if the application was already installed? Or maybe there is already a built-in way to upgrade the old installed files in the specified directory?
Your application should not store its settings in Program Files, they should be stored in CommonAppDataFolder, AppDataFolder, or LocalAppDataFolder. If you use one of these folders to store your application settings/data, then users are free to install it to any other location and the app will still see its settings/data.
As far as I understand, the behavior of upgrade depends on where you schedule RemoveExistingProducts action in the install sequence.
Edit: Since you can't change where your application stores its file, you will have to manually keep track of the install locations. When upgrade operation is performed, the updated product will usually be installed to the same location (this may require a change to your Wizard UI).
If you want to preserve the settings even with manual re-installs, i.e. users uninstalled your app, and then installed it again to another location, the only option I see is to store the install location in the registry. If the value does not exist in the registry, your additional actions should not be run. If the value with location of the previous install exists, you save it. Then you move the settings/data from the old location to the new (by adding temporary rows to MoveFile table). In the end you save the new install location to the registry.
Be aware that storing settings/files in Program Files may not work as expected under Windows Vista and above, especially if UAC is on; and your settings may be actually stored in Virtual Store rather than in Program Files. Updating your application would be much better option than trying to move files around.
Related
I have a WiX bundle that includes the .NET core runtime installer and my product MSI. If I don't tweak anything, I get two entries in the Add/Remove Programs list - one for the bundle and one for the product MSI. I have tried two approaches of showing only one but I run into some issue either way.
Approach #1 - Set MsiPackage attribute "Visible" to "no" in the bundle. This leaves a single entry in Add/Remove Programs (for the bundle).
The problem here is if they do an initial install with the bundle, but later only install the MSI to upgrade, they get 2 entries in the Add/Remove Programs list - the original bundle one and the new product one.
Approach #2 - Set Bundle attributes DisableRemove and DisableModify both to "yes" in the bundle. This gives a single Add/Remove Programs entry - this time for the product MSI, not the bundle.
The problem here is the following sequence:
Install bundle version 10
Uninstall ARP entry (product MSI)
Install bundle version 9
That third step fails because the system sees a version 10 bundle still installed.
Our bundle is 30MB and our product is 3MB. I don't want to have to have every subsequent update download another bundle when I know .NET is already present and not necessary. So what approach can I use to install the bundle originally but later update with an MSI and not run into the issues above?
EDIT: The only approach I can think of is to have a custom action on uninstall which detects whether or not the MSI was dispatched via the bundle (as opposed to standalone) and if it is not, it then uses something like MsiEnumRelatedProducts() to find the product guid for the bundle and inline uninstalls that. Seems super messy and I'm not sure if it would even work or if that invocation would hit some kind of "installer already running" error.
Setting ARPSYSTEMCOMPONENT = 1 in Property Table of MSI installer(or from command line) will prevent it from displaying in Add or Remove programs. So, Your first approach should work after this change.
I think the simplest solution here is to never distribute MSIs and create two versions of the bundle - one that only contains our package, and the other which contains our package plus the .NET runtime. Always mark the embedded MSI as visible=no and have the bundle's entry show up in ARP. This ensures bundles always update bundles, ARP shows the correct version, and that nothing ever gets left behind on an uninstall.
I tried to implement a custom action on MSI uninstall to query the bundle's Upgrade Code and manually remove it. Unfortunately, WiX bundles do not show up to the system as normal products. So while I could manually parse the registry, the more robust APIs like MsiEnumRelatedProducts() cannot be used. Therefore, I think the bundle-of-one is my best solution at this time.
I have a scenario,
On a particular machine, I am installing my custom software with MSI installer. MSI installer is created with PerMachine tag, so software is available for all the users of that machine.
Now,
I installed the software on C:\MyApp\ directory.
Then I modified a few configuration files present in C:\MyApp\Config folder to make sure the software connects with my other services.
I started the application, it's working fine.
Now, on the same machine, I logged in with another user.
I started the application.
MSI windows popup with some progress bar for installation.
It vanishes and the application starts but fails to load.
But all the files I have modified are reverted now, I need to again modify those.
Few points:
My installation direcotry is C:\MyApp, not any custom user directory. So modified files should be for all the users.
I think MSI is rolling back changes when I logged in with the new user.
How to stop this?
Please help
Self-Repair: Windows Installer self-repair is the cause of the behavior you see. See the link for an explanation of what happens. See more here - several links with information on self-repair from various angles.
Short Explanation: Essentially the launching of an advertised shortcut triggers an integrity check of the installed files and if a file or registry setting is found to be missing a self-repair ensues. It will put in place missing files and settings. During this process it will sometimes overwrite changed settings files - the problem you describe (due to various file overwrite oddities of Windows Installer - a long answer with various hints).
Fix?: My preferred fix for this is to not install the settings files and update them, but to rather have your application generate them on first launch - either one file per user or a shared one for all users. You can also use a read-only copy of the settings file that you install to copy to a new file that you generate and update. I also recommend you put these files in a writable location in the user profile and not in the main folder. Your setup will never interfere with these generated files. You can also try to set the hosting component for the files "permanent" and "never overwrite". Not very neat. Here is a whole rant on the subject. The very best solution - in my opinion - is to keep settings in databases and get them on launch. This allows good control of all settings. Look out for network and firewall issues.
I hope this answers your question. Are you installing IIS files? I find commercial tool Advanced Installer to have the better feature list for IIS installation - though I lack enough data to conclude. Some videos here: https://www.youtube.com/c/advancedinstaller/search?query=IIS - WiX is also very good, but without the nice GUI of Advanced Installer.
Note: you really should not install to the root of C:\ anything at all. Windows Installer actively tries to make it hard, and side-effects are likely. You can, however, target the IIS folders - wherever they are located.
Update: I found this old answer on how to allow selective update of settings files - I had to resurrect the linked forum answers from Wayback.
The old version of the setup was created with InstallScope="PerMachine".
The new version is intended to have InstallScope="PerUser"; it also needs to use the same registry keys as the old version creates.
The problem is that whatever values are stored under these registry keys during the upgrade will be overwritten at the end with the initial values stored by the old version. Even deleting these keys manually before the installation will make them reappear (with the wrong values) after the installation process.
I have tried creating a custom action and specifically delete these keys, but the result is the same.
How can I ensure that the old version does not interfere with the installation process of the new version allowing to delete the old Registry Keys and re-create them?
What I found to be working:
Performing a REPAIR immediately after installing the new version will yield the correct results!
Uninstalling the old version manually before installing the new one will not remove the keys, but will allow to overwrite them with the correct values.
You should define what kind of upgrade you are doing, and if it's a major upgrade then where is it sequenced in your major upgrade element, although...
Probably the main issue is that cross context major upgrades aren't supported by Windows Installer, so if you are doing a major upgrade you will end up with both products installed. That's not an upgrade, that's most likely just a collision. So assuming that you want only one of them to be installed at the end of all this, you will need to uninstall the older per-machine installation and then install the per-user. As to why the uninstall of the per-machine product doesn't remove the registry keys, there are many possible reasons, such as they were created by the app not the MSI, or the component was marked permanent, or the component has another client product on the system - a log of the uninstall might show what's going on.
I have to add this as an answer, too long as a comment. I will "evolve" it once you provide more information:
Why do you want to switch to per-user installation? In the MSI world this is not an ideal way to deploy. An application is usable per-user even if installed per machine. With a per-machine install you simply add the ability to write shared settings that should not be overridden by a user. And your application is easier to upgrade, uninstall, patch and manage overall.
Here are a few more links to explain some of the problems with per-user setups. They are real, I am only trying to warn people what problems they are most likely going to face (almost certainly going to face):
Having an issue with WIX upgrade
Understanding “Per-User” or “Per-Machine” context for application Setup packages
Are you deploying HKCU or HKLM keys? I would not recommend writing any HKCU values from your setup, they should be written by the application itself. A setup is for writing to HKLM and other places that require "elevated rights". It should never be used to write user preferences. There will be interference when you do upgrades (as you have experienced).
Where is the registry data you speak of stored? In a single MSI component or several? Is there anything else in that component that still needs to be installed without the registry keys? If you can, please add your source WiX file so we can see for sure.
I am sure that we can make all these problems go away if you follow our advice precisely. You are facing a very common MSI problem.
Let me attempt a tentative answer without having all the information:
Remove all HKCU registry information from your setup (if you can).
Update your application to write these HKCU values itself, and ideally write to a brand new location in the registry instead of the old one. For example HKCU\Software\MyCompany\MyApp\5 instead of HKCU\Software\MyCompany\MyApp. This "decouples" your old and new state, and you got room to maneuver and clean up things.
Making your application write the HKCU keys is not a hack, but the right thing to do. It will make your application much more robust and generally easier to QA for yourself and your team. You can "wipe the slate clean" during testing and start over without a reinstall - in order to focus on application testing.
Put any remaining HKLM settings in a single WiX component and set a good key path that will never be modified or deleted by the user or any other process. For example: HKLM\Software\MyCompany\MyApp\5\MyAppHKLMKeyPath = 1
If you discover that you have to override a value for each user (in other words change something for every user in HKCU), you can do this with this approach which combines what the setup does with the application itself: http://forum.installsite.net/index.php?showtopic=21552 (if this is important, please read the whole, linked thread).
I simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
i am relatively new to Wix. I created a Setup where we can define a connection string on the first install. Now i wanted to upgrade, and have the possibility to skip some Dialogs that are only used in the first install (like the one that asks for the server and database), and i didn't want to remove some XML files that were configured in the first install.
For what i have read, a major upgrade removes the previous installation, and replaces all the files.
How can i get a condition that says if its first isntall or upgrade, to just install some components, skip some dialogs, not reconfigure XML Files (i'm using util:XmlFile) and not remove some files?
Thanks
You could condition the Components and Actions using the Installed property and UPGRADINGPRODUCTCODE property.