.NET, "Any CPU/64Bit (x64)/32Bit (x86)" Best Practices, Tips and Tricks

8
votes

If a .NET program directly or indirectly needs to call platform dependent/native/unmanaged code it might crash.

This 32-bit/64-bit theme came into my mind after I got a new laptop with Windows 7 64-bit installed and tried to develop with the SQLite database.

System.Data.SQLite contains managed code plus unmanaged code. There is a 32-bit version and a 64-bit. Both have the same filename, but different size, and your EXE file must use the right one.

To make it more complicated: My Visual Studio 2010 debugger is a 32-bit application, so I cannot debug when using "System.Data.SQLite-64bit" from the GAC!

As .NET developers we need guidelines/know-how/best practices.

And the best place to collect this kind of information that I know of is this site.

So please, share your ideas and known issues which could serve as best practices or guidelines to survive in the 32/64/anyCPU .NET world.

I would favor one issue/trick per "answer" so it can be commented/updated/referenced easily.

  • feel free to give several "answers".

I will share my own knowledge as answers to this question, too.

1
.net32bit-64bitsample
Though obviously the accepted answer provides you information on bitness of .NET projects, I want to remind you there is a purely bitness friend solution out there, called C# SQLite code.google.com/p/csharp-sqlite. 100% C#. :) - Lex Li

1 Answers

4
votes

Providing an extra "x86 only" main.exe can make live easier when native code is involved

After reading anycpu-exes-are-usually-more-trouble-then-they-re-worth I realised that providing an extra "x86 only" main.exe can make live easier.

Since Windows 7 64-bit can execute x86-32-bit applications the x86-program will run on most .NET-systems (but not on non-Intel Mono systems).

As long as the Windows 7 64-bit Visual Studio 2010 debugger is a 32-bit application the x86 app can be debugged easyly.

The x86 release has as many "any CPU" DLLs as possible except the main EXE and the CPU-specific DLLs.

For machines that cannot run x86-code or where a huge memory is requiered you can provide an extra "any-CPU" EXE-version. This version requies adequate installation to enshure that right platform specific code is used.

Visual Studio 2010 How to: Configure Projects to Target Platforms describes how to set the platform to x64. The same way you can target x86.