I have Wix Installer for my 32-bit Application i.e. it always set up the files in Program Files(x86). SO when the user installs it on the 32-bit machine I want to remove some of the dlls from it.
I am not registering any values in Registry and don't want to that way. Is there any other way than this?
Yes, you do need separate MSI files for 32-bit and 64-bit, assuming that you have 64-code that you want to install and run. 32-bit apps will install on 64-bit systems and run in 32-bit mode, but it appears that you have 64-bit Dlls.
This is a good outline of why you need two installs:
https://blogs.msdn.microsoft.com/heaths/2008/01/15/different-packages-are-required-for-different-processor-architectures/
For example there are different folder locations such as ProgramFilesFolder for 32-bit program files and ProgramFiles64Folder for 64-bit setups.
and this link:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367451(v=vs.85).aspx
points out that 32-bit packages can contain only 32-bit components, and 64-bit packages can contain 64-bit and some 32 bit components.
Related
.Net Assemblies built with AnyCPU will JIT to 64-bit code when loaded into a 64-bit or 32-bit process based on the CPU. I am creating a WiX installer.
What should be the default path (Program File x86/Program File) for the components built with AnyCPU option? Shall the installer check the platform and set the appropriate path or are there any other ways to handle it?
At this point in time, I'd recommend installing to ProgramFilesFolder (Program files (x86)) as that is present on both 32-bit and 64-bit computers. 32-bit is the closest thing (at this time) Windows has for "Any CPU".
Note: This does change as WOW is removed from 64-bit Windows. You can already remove the WOW subsystem from Windows Server, in which case you need to provide a package that targets the appropriate architecture. It isn't clear if/when WOW will be removed from Windows client.
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.
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.
I created an installer for my AnyCPU DLLs. I've marked my assemblies with teh Assembly=.net directive in my project as well. The installer seems to be able to register the COM servers successfully on my XP 32bit machine, but fails to do so in my Windows7 Machine. I did run the installer in admin mode. Also I looked up the Win764 registry and found those CLSIDs in the reigstry. So looks like the MSI did put some entries in the registry but somehow they are not being recognized as valid COM Server entries (OLE Viewer also didnt enumerate my server).
Any idea why this would happen? Any extra config do I need to add to my project?
thanks
Apparently you need to compile your msi as a 64-bit native binary to have the dlls registered in 64 bit mode.