Question

I have a solution where the executable’s target platform was initially set to x86, many other projects were set to AnyCPU, and included 3 projects in .Net 3.5 (everything else .Net 4.0). I presume this is why the installer wrote to the HKEY_LOCAL_MACHINE\SOFTWARE registry key.

Recently, I fixed some issues and now all projects are .Net 4.0. Additionally, I set the executable target platform to AnyCPU. I found the application was now installed in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.

[sidebar – we have p/invokes – DllImport attributes – that did not
specify a CallingConvention. When this was modified both in
managed and unmanaged code to specifiy Cdecl and __cdecl, we were able to
upgrade dependent projects to .Net 4.0 without receiving a PInvokeStackImbalance exception.]

We develop currently with VS2010 on Windows 7 (64-bit) machines.
My question is: Did the installer write to \SOFTWARE\ initially because some of the projects were .Net 3.5?

Also, if this application is intended to be installed on WindowsXP (32-bit is expected to be supported) machines, is the registry key problematic? Better yet, what should I look for in build options that ensures compatibility on WinXp 32-bit systems?

Answer 1

Only a 64-bit installer will avoid Wow6432Node on a 64-bit operating system. In a Setup project, that’s set by the TargetPlatform property of the installer, it defaults to “x86”. Change it to “x64” if you changed the C# EXE project’s Target platform to AnyCPU. This will also ensure that your program is installed to c:\program files and not c:\program files (x86).

You will thus need to maintain two installers. Bit of a headache, you can avoid it by setting the C# EXE project’s Target platform to x86 so both the installer and your program access the key in Wow6432Node.

The pinvoke problem is normally the other way around, 64-bit code has only one calling convention and there’s no difference between cdecl and stdcall.