1

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?

IAbstract
  • 19,551
  • 15
  • 98
  • 146

1 Answers1

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Regarding p/invoke: I'll have to find the link or two that might suggest otherwise and led me to fixing the issues. :) – IAbstract Jul 23 '12 at 19:57
  • The accepted answer of http://stackoverflow.com/questions/3506796/pinvokestackimbalance-how-can-i-fix-this-or-turn-it-off led me to make some corrections in the DllImport call and set the CallingConvention. Then, receiving a compiler error ...couldn't find "XxxEntryPoint", I changed the attribute to `__cdecl` to match the managed calling convention. – IAbstract Jul 24 '12 at 02:16