The problem is a known issue in Visual Studio:
The setup project, even if you set it to be x64 only
(!), always inserts the 32 bit version of InstallUtilLib.dll
into the msi (we had the problem even when building the setup project on x64 machines!)
InstallUtilLib.dll is used to run the C# installer class(es) in your executable.
Since the 32-bit version is used, it always runs your exe as 32-bit when it does the custom action, which means any registry keys affected by redirection will get mapped to Wow6432Node.
A solution is to fix the MSI using Orca to replace the 32-bit InstallUtilLib.dll with the 64-bit version.
A previous colleague of mine even included a project in some of our solutions to do this, and made it automatic by including it to run after the build. (I doubt I would be allowed to provide the code for this).
A second option, and one that I personally have favoured, is to turn my executables into "self-installing" exes. I.e. get it to run the installation classes (using System.Configuration.Install.AssemblyInstaller
) when a /install switch is included on the command line. (An alternative may be to get it to run the installation when it detects that it is the first time it has been run on a machine, such as finding a required registry key is not present).
If you go down this route, don't forget to include /uninstall as well!
This second option makes the installation routine truly "any cpu" because when it is run it will run as 32-bit or 64-bit depending on the CLR in use and will therefore load the correct modules.
I have for the time-being given up with msi completely for new stuff I develop. I simply copy the files into the correct location and run the exe with a /install switch. Even using simple batch scripts to copy everything into the correct location and then run it.
However, I realise this is not a useful solution for wider deployment to joe public (not least because unless you also add all the appropriate install registry keys yourself, the application won't appear in control panel)
. Nevertheless it was the easier option for what we
In your case, fixing the MSI using Orca is probably the way to go.
Let me know if you need more information about how to do it, and I'll see if I can provide it.
In the meantime, look at your MSI using Orca, and you should see what I mean by InstallUtilLib.dll being 32 bit.
Info on Orca.exe (http://msdn.microsoft.com/en-us/library/aa370557(v=vs.85).aspx)
Finally, as an afterthought, I have just found this as a possible alternative; it looks as if you might
be able to switch off "registry reflection" for your keys - see the 4th paragraph on this page. As I say, I've just found this, so I'll leave you to decide if you want to experiment: