VisualStudio C# x64, why AddReference option, .NET tab points to x86 DLL instead of x64?

北城余情 提交于 2019-12-22 12:22:51

问题


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)?


回答1:


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.




回答2:


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




回答3:


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.




回答4:


<Reference Include="32bit.dll" Condition="'$(Platform)'=='x86'"/>
<Reference Include="64bit.dll" Condition="'$(Platform)'=='x64'"/>

Look at this answer:

How to reference different version of dll with MSBuild



来源:https://stackoverflow.com/questions/1978340/visualstudio-c-sharp-x64-why-addreference-option-net-tab-points-to-x86-dll-in

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!