构建x64版本时CS1607编译器警告

Cap*_*mic 16 .net 64-bit

当我在Windows Server 2003上使用Visual Stuido 2008构建我的.net应用程序的x64版本时,我得到了

警告CS1607:程序集生成 - 引用程序集"mscorlib.dll"针对不同的处理器

这是否意味着我没有安装x64版本的.NET?

完整报告在这里

16> C:\ WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe/noconfig/nowarn:1701,1702/platform:x64/errorreport:prompt/define:DEBUG; TRACE/reference:..... .....\BIN\Jfc.Dealing\Jfc.Configuration.ConfigurationLayer.dll /reference:work..\BIN\Jfc.Dealing\Jfc.Sys.dll/reference:D:\ Projects\dzhukov\SourceCode_Integration_branch\TradeProcessor\Jfc\QuikExport\bin\x64\Debug\QuikExport.dll /reference:D:\Projects\dzhukov\SourceCode_Integration_branch\Samples\JFC\FxGate\QuoteFeedWcfRemoteControl\bin\x64\Debug\QuoteFeedWcfRemoteControl.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.configuration.dll/reference:"c:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll"/reference:"c:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Data.DataSetExtensions.dll"/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll/reference:C :\ WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Messaging.dll/reference:"C:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.Runtime.Serialization.dll"/ reference :"C:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System.ServiceModel.dll"/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll/reference :"c:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll"/ debug +/debug:full/filealign:512 /out:obj\x64\Debug\FeedRawQuotes.exe/target:exe FeedRawQuotes.cs FeedRawQuotesConfiguration.cs MSMQFeed.cs Program.cs Properties\AssemblyInfo.cs警告CS1607:程序集生成 - 引用程序集'System.Data.dll'针对不同的处理器警告CS1607:程序集生成 - 引用程序集'mscorlib.dll'针对不同的处理器

Han*_*ant 36

这是一个正常的警告,当您明确指向x64时,您将始终获得它.它在运行时不会成为问题,因为在64位计算机上,GAC存储了一个64位特定版本的mscorlib.dll.

长版本:多个.NET程序集包含非托管代码.这使得它们对使用它们的进程的比特敏感.Mscorlib.dll是其中之一,System.Data.dll和WPF程序集是其他示例.Microsoft通过构建这些程序集的两个版本(32位和64位)解决了这个问题.GAC可以存储它们,由AssemblyName.ProcessorArchitecture属性解析.此属性的"正常"设置是MSIL,在程序集包含纯IL时使用.然后,32位和64位进程都可以使用该程序集的单个副本.

编译器使用的引用程序集是.NET程序集的副本.编译器纯粹将它们用于元数据.但是,这些副本是32位程序集的副本,它们将ProcessArchitecture设置为X86,用于包含非托管代码的程序集.

您可以看到它的位置,您正在编译x64并且编译器会看到x86引用程序集.足以生成警告" 只有当您还提供程序集的x64版本时,此程序才会起作用"..NET程序集当然就是这种情况,但不一定适合您自己的程序集.

也许值得注意的是,这是在.NET 4.0中解决的.它使用非常不同的参考组件,存储在其中C:\Program Files (x86)\Reference Assemblies.与v2参考程序集不同,它们与GAC中的副本完全不同.所有MSIL都从它们中删除,它们只包含元数据.并且是AnyCPU,因此不再有任何警告.用于创建它们的工具很有趣,遗憾的是微软不会与我们分享它.

明确针对x64的Fwiw几乎总是错误的做法.它只对EXE程序集很重要,因为它决定了进程的位数.DLL程序集没有选择,适当的构建设置是Any CPU,因此它们可以双向工作.罕见的例外是DLL对非托管组件(通常是COM服务器)具有已知依赖性.这些组件通常仅作为32位图像,你会得到一个难以诊断的错误消息,当您尝试加载它们在64位进程("类没有注册").通过强制它们以x86为目标,你会得到另一个难以诊断的异常,这可能会让眼睛更容易一些,BadImageFormatException.依赖于仅在64位代码中可用的非托管代码是非常罕见的,因此针对x64没有多大意义.