构建64位版本时，CS1607编译器警告 [英] CS1607 compiler warning when building the x64 version

问题描述

当我建立的x64我的.NET应用程序版本的Visual Stuido 2008年Windows Server 2003上 我得到

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

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

报告全文在这里

  

16> C：\ WINDOWS \ Microsoft.NET \框架\器v3.5 \ CSC.EXE   / noconfig / nowarn：1701,1702   /平台：X64 / errorreport：提示   /定义：DEBUG，TRACE   /reference:..........\BIN\Jfc.Dealing\Jfc.Configuration.ConfigurationLayer.dll   /reference:..........\BIN\Jfc.Dealing\Jfc.Sys.dll   /reference:D:\Projects\dzhukov\Source$c$c_Integration_branch\TradeProcessor\Jfc\QuikExport\bin\x64\Debug\QuikExport.dll   /reference:D:\Projects\dzhukov\Source$c$c_Integration_branch\Samples\JFC\FxGate\QuoteFeedWcfRemoteControl\bin\x64\Debug\QuoteFeedWcfRemoteControl.dll   /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.configuration.dll   /参考：C：\ Program Files文件\参考   大会\微软\框架\器v3.5 \ System.Core.dll的   /参考：C：\ Program Files文件\参考   大会\微软\框架\器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   /参考：C：\ Program Files文件\参考   大会\微软\框架\ 3.0 \ System.Runtime.Serialization.dll   /参考：C：\ Program Files文件\参考   大会\微软\框架\ 3.0 \ System.ServiceModel.dll   /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll   /参考：C：\ Program Files文件\参考   大会\微软\框架\器v3.5 \ System.Xml.Linq.dll   /调试+ /调试：全/ filealign：512   /out:obj\x64\Debug\FeedRawQuotes.exe   /目标：EXE FeedRawQuotes.cs   FeedRawQuotesConfiguration.cs   MSMQFeed.cs的Program.cs   属性\ AssemblyInfo.cs中警告   CS1607：集生成 -   引用程序集System.Data.dll中   针对不同的处理器警告   CS1607：集生成 -   引用程序集mscorlib.dll中'   针对不同的处理器

解决方案

这是一个正常的警告，你总是会得到它，当你明确目标64。这不会是在运行一个问题，因为在64位机器上，海关总署存储mscorlib.dll中的64位特定版本。

长版：几个.NET程序集包含非托管code。这使得它们对使用它们的过程的位数敏感。 mscorlib.dll中是其中之一，System.Data.dll中的WPF程序集是其他的例子。微软通过建立两个版本的组件，32位之一，64位处理解决这一点。海关总署可以存储他们两个，由Ass​​emblyName.ProcessorArchitecture物业解决。在正常设置该属性是MSIL，使用时组装包含纯粹的IL。的组件的单拷贝然后可以使用由双方的32位和64位的过程。

由编译器使用的引用程序集是.NET程序集的副本。编译器使用他们纯粹是为了自己的元数据。这些副本都不过32位组件的副本，他们将有ProcessArchitecture设置为X86为包含非托管code组件。

您可以看到这个的话，你编译支持x64和编译器看到一个x86参考汇编。足以产生一个警告，这个计划是去工作的只有的，如果你还为大会x64版本。这当然是对.NET程序集的情况，但并不一定是你自己的。

也许值得注意的是，这是解决在.NET 4.0中。它使用了非常不同的参考组件，它们存储在 C：\ Program Files文件（x86）的\参考大会。不同于V2的引用程序集，它们都是从副本在GAC完全不同。所有MSIL从他们剥离，他们只包含元数据。并且值为anycpu，因此没有警告了。这是用于创建它们的工具是有趣的，遗憾的是微软并没有与我们分享。

FWIW，明确目标64几乎总是错误的做法。它只真正重要的EXE程序集，因为这是一个确定的过程中位数。一个DLL组件没有选择，相应的创建设置对他们来说是任何CPU，使他们可以是双向的。在罕见的例外是，DLL有一个已知的依赖于一个非托管的组件，通常是COM服务器。这些组件通常仅作为32位图像，你会得到一个很难当您尝试加载它们在64位进程（类没有注册）诊断错误信息。迫使他们的目标86，你会得到另一种很难诊断异常可能是对眼睛， BadImageFormatException 更容易一点。有非托管code一种依赖，仅在64位code可以是相当罕见的，因此针对64位并没有太大的意义。

when i build x64 version of my .net app with Visual Stuido 2008 on Windows Server 2003 i get

warning CS1607: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor

Does it mean I have not installed x64 version of .NET?

Full report is here

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:..........\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 warning CS1607: Assembly generation -- Referenced assembly 'System.Data.dll' targets a different processor warning CS1607: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor

解决方案

This is a normal warning, you will always get it when you explicitly target x64. It won't be a problem at runtime because on a 64-bit machine, the GAC stores a 64-bit specific version of mscorlib.dll.

Long version: several .NET assemblies contain unmanaged code. Which makes them sensitive to the bitness of the process that uses them. Mscorlib.dll is one of them, System.Data.dll and the WPF assemblies are other examples. Microsoft resolved this by building two versions of those assemblies, a 32-bit one and a 64-bit one. The GAC can store them both, resolved by the AssemblyName.ProcessorArchitecture property. The 'normal' setting for this property is MSIL, used when the assembly contains pure IL. A single copy of the assembly can then be used by both a 32-bit and a 64-bit process.

The reference assemblies used by the compiler are a copy of the .NET assemblies. The compiler uses them purely for their metadata. Those copies are however copies of the 32-bit assemblies, they'll have the ProcessArchitecture set to X86 for assemblies that contain unmanaged code.

You can see where this goes, you are compiling for x64 and the compiler sees an x86 reference assembly. Enough to generate a warning "this program is going to work only if you also provide the x64 version of the assembly". Which is certainly the case for .NET assemblies, but not necessarily for your own.

Perhaps notable is that this was solved in .NET 4.0. It uses very different reference assemblies, which are stored in C:\Program Files (x86)\Reference Assemblies. Unlike the v2 reference assemblies, they are drastically different from the copy in the GAC. All the MSIL was stripped from them, they only contain metadata. And are AnyCPU, thus no warning anymore. The tool that was used to create them is interesting, unfortunately Microsoft doesn't share it with us.

Fwiw, explicitly targeting x64 is almost always the wrong thing to do. It only really matters on the EXE assembly since that is the one that determines the bitness of the process. A DLL assembly doesn't have a choice, the appropriate build setting for them is Any CPU so they can work both ways. The rare exception is that the DLL has a known dependency on a unmanaged component, typically a COM server. Such components are typically only available as 32-bit images, you get a hard to diagnose error message when you try to load them in a 64-bit process ("Class not registered"). By forcing them to target x86, you'd get another hard to diagnose exception that is perhaps a bit easier on the eyes, BadImageFormatException. Having a dependency on unmanaged code that is only available in 64-bit code is quite rare, therefore targeting x64 doesn't make much sense.

这篇关于构建64位版本时，CS1607编译器警告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！