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.
Related
When I go to register a dll as an admin on my machine it works fine:
Regsvr32 C:\nameofdll.dll
However when I run it on another machine it fails.
Why is that?
Error codes: Error codes can be looked up using one of these methods.
Regsvr32.exe - Admin Rights Required: As far as I know self-registration requires admin rights since it registers the DLL per-machine - or in other words in the HKLM / HKCR sections of the registry (HKCR is a view into a part of HKLM and a merge from sections of HKCU - in other words it is an "emergent view" from both HKCU and HKLM). Now I see this answer which seems to indicate that there are ways to register COM servers per user? It doesn't work for my test OCX files using this method. I did not try the custom registration EXE from codeproject.
MSI - Per-User COM Registration: Windows Installer - on the other hand - is able to install COM servers per-user for setups that install per-user. Per-user setups are bad for a number of reasons (serviceability, upgrading, patching, various limitations), but that is another story. If you enable Installshield's COM Extract On Build as I showed in another answer, the COM data is added to your MSI in a way that ensures that the COM server can be registered per-user - if the setup is installed per-user, or per-machine if the setup is installed per-machine. This is the standard way to register COM files using Windows Installer.
Bitness: Other problem causes are possible, such as the mentioned "bitness" of the COM server. I have encountered very few x64 COM servers, but they are problematic to deal with using WiX for example. As far as I know the WiX 3.11 release does not support x64 COM servers for extraction. Similar problems could exist in Installshield - I don't know.
Support Page: On a 64-bit version of Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe
Lacking Dependencies: Self-registration can also fail if there are lacking dependencies for the file in question. You can use a tool such as dependency walker to check, or you can monitor with procmon or any number of scanner tools (have a quick skim). Note that it is also possible that you lack a "language dll" for the COM server. For example: MyApp-English.dll. Such a file should be located next to your main COM server file MyApp.dll or MyApp.ocx to allow registration to work correctly.
Oddities: Numerous other problems can be seen. Ranging from licensing issues, COM interoperability with .NET (regasm.exe), interference from weird security policies, security software interference - anti virus etc... To any number of other specific and rare factors.
Warning: I have seen self-registration perform illegal actions and change core system values during the self-registration process - without any warning or explanation. Hence the recommendation to avoid
self-registration during deployment whenever possible.
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?
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.
I'm writing merge modules for a project I'm working on.
I build two merge modules, one for 32-bit and one for 64-bit. I want to include them in a WiX installer but it tells me I can't:
error LGHT0345: 'installer\bin\x64\Release\en-us\myproject.msm' is a 64-bit merge module but the product consuming it is 32-bit. 32-bit products can consume only 32-bit merge modules.
Is there a way to make a dual CPU project so I can include both?
WiX version is 3.6.
Windows Installer doesn't support multi-platform packages. If you need to write to the 64-bit portion of the file system or registry, you need a 64-bit package.