I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I’m expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I’m stuck with using Visual Studio’s deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
- it is marked as a x64 installer
- it writes the entries under
HKLM/Software/Blablahfor the benefit of 64-bit processes - it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablahfor the benefit of 32-bit processes on the same machine.
I’m guessing that because I’ve marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.
The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it’s much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You’ve got to produce the 32 bit package anyway for 32 bit machines, so it’s no extra work.