Our company uses WIX for its installers, and we are now upgrading our application from 32-Bit to 64-Bit. For every new version, we always provide an upgrade path from the previous ones.
TODO list :
Binaries should now reside in the "C:\Program Files" folder instead of "C:\Program Files (x86)".
Registry entries should now reside in HKEY_LOCAL_MACHINE\SOFTWARE\%COMPANY% instead of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\%COMPANY%
Log files, configuration files, and any custom files/registry entries needs to be moved over to their new 64-Bit locations.
Considered the special aspect of this upgrade, we are inquiring the community regarding its know-how.
Presumably you'll continue to have a 32bit MSI for 32bit customers. So I'd approach this was another MSI and reuse as many fragments as possible. Your directory table and ComponentIDs will be different and I'd also give it a different UpgradeCode GUID. In your MajorUpgrade I'd search for products having the 32bit UpgradeCode and the 62bit UpgradeCode and remove both when found.
I'd also make sure that you need to even do this. For example if I deploy a .NET app with no native dependencies ( say IIS, Winforms, WPF, Windows Service ) it'll JIT up 64bit no problem when possible even though I installed it using a 32bit MSI to 64bit locations. No harm no foul.
Related
We have migrated our app from net472 to net6.0-windows. There is a wix installer for the app.
Currently the installer's upgrade sequence from net472 to net6.0-windows doesn't work as expected.
This is because there is a bunch of third party libs which have have the same file version for different platforms in net472 and net6.0-windows. e.g. NLog.dll would be 4.7.7.12472 in both platforms.
AFAIU, the file replacement rules work so that when source file(assembly in installer) and target file(installed assembly) version are equal, the installer will not replace this file.
So now after the upgrade, the bin folder is left with a mix of old(net472 from 3rd parties) and new(mostly our 'file version incremented' net6.0-windows) assemblies.
Any recommendations on how to solve this upgrade problem?
This is an example of broken component rules (by third parties). The windows installer thinks it's good because the versions are the same but the files are not forward or backwards compatible.
Unless you want to set the REINSTALLMODE property to amus (forced overwrite of everything ) or do file by file version lying (file version attribe 65535.65535.65535.65535 to force that file to always overwrite ) you will need to do a MajorUpgrde scheduled afterInstallValidate.
Other possibilities is to treat this as a new product and install to a new directory or consider alternate .NET compile/publish options so that the app self contains those files without the installer ever seeing them.
I migrated a Visual Studio Setup Project to WiX.
If I upgrade the Software installed by WiX with a WiX Setup (increased Minor Version), it upgrades fine.
But If I try to upgrade the Software installed by VS Setup, with my new WiX Setup, it does not remove the old Installation. And I kept the same Upgrade Id.
Is this not possible?
What does it do? You get two entries in Programs and Features after you try to do the upgrade?
If the upgrade codes are identical, and the product codes are different, and the new one has a higher version, the most common reason is that the older install is per user and the upgrade is per system (or the other way around). In VS setups that's the "Just me" setting, and it might be the default.
But yes, it is possible. It's nothing to do with the tool you use to build the MSI file, it's a feature of MSI files and Windows Installer.
Since I wasn't a part of my company when our build process was designed and implemented (and has been successful for quite a few years now), I found out that there were things that were being done that may be looked at as 'hacks' to MSI 'purists'. However, in order to get a workable installer with Visual Studio 2012, I've been doing the best I can to mimic what was being done with the .vdproj files in Visual Studio 2010. Of the many snags I've hit, this one seems to be the last one that I can't resolve.
As part of our build process with Visual Studio 2010, we built our code and created a Framework MSI on one VM. Then we took that Framework MSI and installed it on a different VM. After the framework had been installed, we built our product code and created a Product MSI off of it. This created a Product dependence on our Framework. What this meant was that when installing on a client machine, the bootstrapper needed to install the Framework first followed by the Product. On uninstall our documentation stated to either have it handled through ARP or by command line 'msiexec /x {Product.msi/#ProductCode}' and then the 'msiexec /x {Framework.msi/#ProductCode}'.
At the time, management determined that the ProductCode would be the easiest way for other product teams to determine if our product had been installed on a machine. This lead them to the decision that they needed to keep a static ProductCode for both the Framework and the Product.
In order to handle upgrades, they had to create a ProductTool.exe that was nothing more than the msiexec wrapped in an executable that took a /ProductCode={#ProductCode} argument.
As part of our bootstrapper, they called:
Install prerequisites (Windows Installer 4.5, .NET 3.5 SP1, SQL Server 2008 R2 Express, Sync 2.1)
ProductTool.exe (Product.msi -- to uninstall the Product.msi)
ProductTool.exe (Framework.msi -- to uninstall the Framework.msi)
Install Framework.msi
Install Product.msi
However, I didn't discover until just recently that the Burn bootstrapper does not allow REINSTALLMODE=amus. In the install logs, it says that it changes it to REINSTALLMODE=vomus. Apparently in order to get that aforementioned process to work on upgrades, they had to set REINSTALLMODE=amus.
UPDATE: I finally got to talk to the original developer of the installer and found out that REINSTALLMODE=amus was used intentionally to revert all of the versioned files (assemblies, DLL files, etc.) and non-versioned files (.config, SQL script, etc.) as a risk minimization and robustness/"self-healing" strategy.
Having said all of that, is it even possible with a standard burn bootstrap application (BA) to set REINSTALLMODE=amus so that I can get the upgrades working? The MSI files have the Property's set, but Burn seems to override it.
No, this is not supported by the Burn engine today. Burn controls the REINSTALLMODE very carefully to correctly handle upgrades and repairs. Using a in REINSTALLMODE is far from a best practice and thus is not supported. Also, it isn't clear why a is necessary in the scenario you described.
In install4j, can you include both 32 and 64 bit versions of an application in one install package and let the user decide which to install if the OS is 64-bit? Would the easiest/best solution be to create three projects? i.e. one parent/two children? I'm hesitant to do this because the majority of the included files are not architecture-specific and I'd like to keep everything in one project.
I'm also not tied to install4j if another installer can accomplish this, especially WiX, which is used by other groups in our company.
Currently install4j cannot create a single media file for 32-bit and 64-bit. Since the 32-bit media file works on 64-bit Windows as well, this is usually not a big problem. Common 32-bit/64-bit media files may be implemented for install4j 6.
In any case, you do not need separate projects for 32-bit and 64-bit installers. You just add two media files in the "Media" step of the install4j IDE, one for the 32-bit installer and another one for the 64-bit installer, with different settings on the "32-bit or 64-bit" step of the media wizard.
As for platform specific files, just add two file sets and exclude them as appropriate in the "Customize project defaults->Exclude files" step of the media wizard.
I'm using WiX to deploy my application. This application uses a registry key which is shared between x64 and x86 processes. Thus it must not use the Wow64Node. The application uses the KEY_WOW64_64KEY flag to achieve this.
But how can this be done using an MSI build with WiX? Currently I use an x86 and an x64 version of the installer, but that gives me a large overhead. Is it possible to disable registry redirection in WiX? I found the DisableRegistryReflection attribute, but that does not seem to have influence on redirection. Another idea would be to merge the two installers into a single file, like it is possible with languages. But I have in mind that that's not supported.
This could be done with an unified 32/64-bit package, but WiX doesn't support it. Some commercial setup authoring tools support it.
When using separate packages, 32-bit installers will use the 32-bit location on 64-bit systems. So to avoid registry redirection you should distribute a 32-bit package for 32-bit systems and a 64-bit package for 64-bit systems.
In 64-bit installers the registry entry component needs to be marked as 64-bit. In WiX you can do this by setting Win64 to "yes" for your registry components.