views:

557

answers:

1

I have a csproj that has a reference to the Framework64 version of System.Data. When I try to build using MSBUILD/TFS on another machine it fails as the 64-bit DLL doesn't exist. Should I bind to the Framework version, or will this limit me when running on 64-bit machines? Does .NET redirect the binding to use 64-bit when possible?

+1  A: 

I think you mean AnyCPU in your question, correct? Assumming that's the case, binding without regard for bit'ness is the way to go in nearly all circumstances.

Recall that .Net code is JIT'd (Just In Tim compiled) -- meaning 32 bit and 64 bit code out of a C# or VB compiler is the same no matter what architecture you plan to run on. When the code is JIT'd at runtime, that's when it becomes 32 or 64 bit.

In some situations, you do have to mind the target architecture. One specific case would be any references/dependencies on COM-wrapper DLLs, .Net Framework supplied or otherwise. This being that these DLLs will be marked (in the case of COM) as 32 bit only (as COM is 32 bit only architecture) if they were not marked as 32 bit, interop to COM would not function. Therefore, since they are explicitly marked, your project outputs should be as well.

Peter Meyer
So why are there 64-bit and 32-bit DLLs in the framework. Are they pre-optimized to be JITed? Or are they pre-optimized to call 32/4-bit "WIN32" APIs?
Geoff Cox
I wasn't sure about this, but my belief was that some of the system assemblies are tightly integrated with native code. This old blog post would seem to suggest that: http://blogs.msdn.com/junfeng/archive/2004/08/11/212555.aspx
Peter Meyer