I have a bunch of MSI installers written using Visual Studio 2015 setup projects, deploying assemblies targeting .NET 4.6.1 AnyCPU. They all implement major upgrade behaviour using the RemoveExistingProducts action, which is sequenced immediately after InstallInitialize. They have .NET custom actions which do things like:
- create an event source
- write
TARGETDIRto a specific registry path for later use - tweak IIS virtual directory properties
- change the contents of the installed
web.configfile depending on installer variables passed in on themsiexeccommand line
This system has worked well until now. However, I recently made a code change to the custom action assembly in the last release which alters the web.config rewriting logic. When the latest release is installed over a previous release, the custom action behaves as if it was the previous version of the code, which is causing errors at runtime.
I can reliably reproduce this in testing. If the previous release is uninstalled, then the latest release installed, then the new custom action code is executed. However, if the previous release is installed, then the latest release installed, then the old custom action is executed. It looks like the MSI engine is caching the custom action assembly in memory, then upgrading it, then running the cached copy instead of the new copy. In the MSI install log I see entries like this, which seem to imply that caching is happening:
Invoking remote custom action. DLL: C:\Windows\Installer\MSIA101.tmp, Entrypoint: ManagedInstall
Obviously the workaround is to tell users to uninstall the previous release before installing the latest release, but I would like to find a better solution. Is there any way to solve this problem (e.g. by changing the install sequence), or is it inherent behaviour in the MSI engine that can't be changed?
Question: What conditioning are you using for these custom actions?
In the setup project, the 4 custom actions are defined with empty Condition properties. In the MSI, the setup project compiler has generated .install, .commit and .rollback custom actions with a condition of $C__3FCB03426E0FFFAE124BDE463AABF3E8>2, and a .uninstall action with a condition of $C__3FCB03426E0FFFAE124BDE463AABF3E8=2. The GUID is the component ID of the service exe being installed.
