Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have a C# Visual Studio project (.csproj) that has a reference to the Framework64 version of System.Data. When I try to build using MSBuild/Team Foundation Server (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?
I think you mean Any CPU in your question, correct? Assuming that’s the case, binding without regard for bitness is the way to go in nearly all circumstances.
Recall that .NET code is JITed (Just In Time compiled) — meaning 32 bit and 64 bit code out of a C# or VB.NET compiler is the same no matter what architecture you plan to run on. When the code is JITed 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 DLL files 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.