I want to create an x64 application.
When I want to add a reference for example to system.data in window AddReference under tab .NET I see only x86 DLLs, and I need 64 bit versions.
I have Windows Server 2008 x64 with Visual Studio 2008.
I created a project and I set x64 under Configuration Manager.
What can I do to force Visual Studio to point to the
correct DLLs (from C:\WINDOWS\Microsoft.NET\Framework64 instead
of C:\WINDOWS\Microsoft.NET\Framework)?
Short answer: Don't worry about that - just add the reference and .NET will load the correct assembly at runtime.
Long answer: Pure .NET assemblies (such as all the system ones) are not actually x86 or x64. They are in an intermediate language (MSIL), which gets compiled ("just in time") to native x86 or x64 code when run. The path you see in the Add References dialog is not actually added to the project (well, it might be, but only as a "hint"). The project actually refers to the strong name of the assembly - its name, version, culture and public key. At runtime .NET will use this information to locate the assembly and it may well be loaded from a different path than where you added the reference from. It's a bit counter-intuitive, but that's how it works.
You can check this for yourself if you watch the debug output window when you start the application: you will see something like:
Loaded 'C:\WINDOWS\assembly\GAC_64\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll', Skipped loading symbols.
... even though the reference path was probably something like c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
The compiler uses reference assemblies only to load type information. That comes from the assembly's metadata. The metadata for x64 specific assemblies is identical to that for x86 assemblies. So, it doesn't matter. The compiler does generate a warning for it, you can freely ignore it if you know the 64-bit version of the assembly is installed in the GAC. It will be when you've got the 64-bit version of the framework installed.
One thing you probably should not do is select x64 as the Platform Target for your project. This is only required if you must use unmanaged code that is only available in 64-bit machine code. COM servers, usually. That is very rare, the typical problem is only having the 32-bit version available. Leaving the target set to Any CPU is the better choice, your binary will run on either platform. And the compiler warning will disappear.
Running into the same problem, and yes I also consider it a bug from MS. You'd think either the x64 or x86 sgen.exe could handle msil assemblies, especially when you have to reference framework assemblies.
I would prefer building msil assemblies myself, but have a native-built 3rd party assembly tossed into my mix. When the project tries to generate the serialization assemblies using the x86 sgen.exe, it complains that the 3rd party assembly is "the wrong format."
When I use the x64 sgen.exe, it complains that System.Data is "the wrong format". But I don't have the option of pointing at the Framework64 version in the .csproj file.
<Reference Include="32bit.dll" Condition="'$(Platform)'=='x86'"/>
<Reference Include="64bit.dll" Condition="'$(Platform)'=='x64'"/>
Look at this answer:
http://stackoverflow.com/questions/1997268/how-to-reference-different-version-of-dll-with-msbuild