For our product we don't want to bother the user with different installers depending on system architecture. Now we want to install only the x64 binaries on an x64 Windows and only ARM64 binaries on a native ARM64 Windows.
It puzzles me that there seems to be no built-in functionality for this. Of course I could write a custom action and find out via IsWow64Process2, but this seems a bit overengineered for such a simple thing!
Did I overlook some easy way to do this?
According to the documentation for the WiX Package element, this could be specified using the Platform attribute, however the docs also state that this attribute should be avoided in favour of the -arch flag on the command line.
Related
What are all the things we should take care of while writing a WiX installer for 64-bit software?
What if I want to support both 32- and 64-bit versions?
I want to release one version of the installer, that will be possible to install softwares for both platforms, according to the host OS.
Separate MSIs for separate architectures:
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
and people use a WiX bundle to choose which depending on the system.
You can have a common source file for both MSIs, this kind of thing:
http://blogs.msdn.com/b/astebner/archive/2007/08/09/4317654.aspx
http://alekdavis.blogspot.com/2011/05/build-32-and-64-bit-installers-using.html
I have an InstallShield Basic MSI project which builds both 32-bit and 64-bit installers using Release Flags mechanism to build the different packages with the correct Template Summary, etc. One of my Components is an explorer.exe shell extension, so in order for this to work it needs to be registered in the 64-bit node in the registry when installed on windows 64-bit, NOT in the Wow6432Node. However, because this is a 32-bit Component to Windows Installer it will get registered as such and go down the Wow6432Node. I am told by InstallShield that this is native Windows Installer behavior and there is really no way around this other than Custom Actions (which I have already resorted to).
Do I have to resort to running regasm? This is what I currently do however I would rather not use Custom Actions for something like this. Also, it appears that other products have the same pattern: a 64-bit shell extension, however installed down program files (x86). I see TFS Power Tools and WinZip doing this for example. For these products, I do NOT see regasm.exe running so I assume they have some other mechanism for this.
Any ideas?
Did you try to set msidbComponentAttributesDisableRegistryReflection (Component table) attribute for that component?
I have x86 and x64 installers of a product building from the same wix source. What I'm looking at now is handling situations where a customer has installed the x86 software and attempts a Major Upgrade with x64 media, and vice versa. I don't want to allow either of those to happen.
I had originally imagined looking for the presence of a HKLM/SOFTWARE registry key we set, but that won't work with x64 installed and an x86 upgrade - the latter won't be able to see it from the WOW64'd registry.
My current idea is to use two different UpgradeCodes for x86 and x64, and add some <Upgrade> trickery to have it abort if the other one is installed. Is this the best way to go out about it, or is there something better?
Two UpgradeCodes is the right thing if you are splitting into two incompatible product lines, which seems to be the case because you want them mutually exclusive. In that case you could use an Upgrade search to detect the incompatible x86, except that FindRelatedProducts runs fairly late in the install after ALLUSERS has been chosen, maybe some dialogs shown, and has the (being picky) issue that you can't cross detect per user and per machine. So I don't like that solution.
I'd find an x86 component in the x86 product and search for it using an AppSearch for that component guid. That happens really early and can most likely be used in a launch condition because AppSearch is before LaunchConditions. Then the user doesn't see anything at all except a message saying they can't install this because that other product is installed. Or maybe a registry item or something that can be used as a launch condition to prevent the install at launch condition time.
I want to distribute standalone software, but the "Build" option in VB.NET doesn't include the CLR. I don't want to hassle users with downloading the CLR, is there some way I can include it in the build?
No, it needs to be installed as a standalone component. You can get reduced size redistributables, but something has to be installed.
If you want to build an Installer with Net included, use WiX. It is a full blown installer + bootstrapper for free. But expect a day or two while you figure thinks out - it is a complex topic and WiX is like every other OSS product: The documentation is as usefull as hard rock at cleaning your posterior....
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.