Windows 7 64-bit C# Build: 'Any CPU' or 'x86' ?

Development PC: Windows 7 32-bit, Visual Studio 2008
C# app: .Net Framework 2.0

My latest version doesn't work under Windows 7 64-bit (it can't find a registry path with some keys). That happens only on PCs with this OS.

I maintain my c# application since 2005 and I always had 'Any CPU' as Platform target option under Build page in project's properties.

The solution for my problem was changing that property to 'x86'.

This is very strange, because my previous version was built with 'Any CPU' and worked on Windows 7 64-bit as well.
I don't find any difference in the project properties between the two versions.

I really can't explain it. Could you?

Need to compile on x64 to deploy to x64. You can set ANY, and it should work, as long as you INSTALL the required files

I have 64bit Vista (obviously running on a 64bit CPU) and for pure c#/MSIL applications Any CPU works great. Binaries which I had written when I had a 32bit system now automatically run in 64bit thanks to JIT compilation!

The only issue is when using P/Invoke to call 32bit code in which case I need to specify x86 now. How do you access the registry ?

Here is a great article which talks about the whole issue, including accessing the registry:

http://lambert.geek.nz/2007/10/02/net64/

Thank you guys for your answers.

@dglienna
I started developing my application 5 years ago, 64-bit app were not a big issue then. I never touched the 'Any CPU' property and when I first installed my app on Windows 64-bit, the program has been installed under Program Files x86 folder automatically, and worked correctly.
The Microsoft Visual Studio setup project automatically detects the required files and includes them into the setup package.

At first, my experience with Windows 64-bit was exactly what Zaccheus experienced.

I don't really understand what's the difference between the current version (that needs 'x86' option) and the previous ('Any CPU') that used to work properly on both 32-bit and 64-bit.

My application doesn't do any strange thing that justifies such a misbehaviour on 64-bit. I consider accessing the registry a quite common operation.
My app looks for keys under
[HKEY_LOCAL_MACHINE\SOFTWARE\Argo\ArgoTool]
which is actually stored in another path (when installed on Windows 7 64-bit). But the OS should take care of it automatically, and it did, since my latest version.

@Zaccheus
I access the registry using the Microsoft.Win32.Registry class

Code:

---

                                m_CurrentUserKey = Registry.CurrentUser.CreateSubKey(m_RegistryCompanyPath);
                                m_CurrentUserKey = m_CurrentUserKey.CreateSubKey(m_RegistryProgramName);
                                m_LocalMachineKey = Registry.LocalMachine.OpenSubKey(m_RegistryCompanyPath + @"\" + m_RegistryProgramName);

---

You have to run the program (and VS as Administrator)

Quote:

---

Originally Posted by MontgomeryBurns

My application doesn't do any strange thing that justifies such a misbehaviour on 64-bit. I consider accessing the registry a quite common operation.

---

Did you not read the article which I linked to? A quick summary:

But wait — which Registry are you actually talking to? You see, in 64-bit Windows there are effectively two Registries. One that 32-bit apps use, and one for 64-bit apps. It’s structured so that a 64-bit app accessing HKLM\Software\Foo will access the 64-bit Registry, and a 32-bit app using the exact same path will access the 32-bit Registry instead.

You see, your shiny new .NET 2.0 app will by default be running in 64-bit mode on 64-bit versions of Windows. This means that it will be accessing the 64-bit Registry, and will only be able to talk to 64-bit libraries.

If all you’re trying to do are simple things like reading/writing paths from the Registry just change your Registry code (that wants to get to the 32-bit Registry) to access HKLM\Software\Wow6432Node\Foo instead of HKLM\Software\Foo.

Quote:

---

Originally Posted by MontgomeryBurns

The solution for my problem was changing that property to 'x86'.

---

That's because it causes your application to automatically access the 32bit registry.