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

Question

当我建立的Windows Server 2003 我得到

警告CS1607在使用Visual Stuido 2008年我的.NET应用程序的x 64版本的：程序集生成 - 引用程序集“mscorlib.dll中”针对不同的处理器

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

报告全文这里

16> C：\ WINDOWS \ Microsoft.NET \框架\ v3.5版本\ CSC.EXE /noconfig/nowarn：1701,1702 /平台：X64/errorreport ：提示 /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 \样本\ 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 程序集\ 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 \ 64 \调试\ FeedRawQuotes.exe /目标：EXE FeedRawQuotes.cs FeedRawQuotesConfiguration.cs MSMQFeed.cs Program.cs的 属性\ AssemblyInfo.cs中警告 CS1607：程序集生成 - 引用程序集“System.Data.dll中' 针对不同的处理器发出警告 CS1607：程序集生成 - 引用程序集“mscorlib.dll中” 目标不同的处理器

Answer 1

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

长版本：几个.NET程序集包含非托管代码。这使得它们对使用它们的过程的位元敏感。 Mscorlib.dll是其中之一，System.Data.dll和WPF程序集是其他示例。微软通过构建这些程序集的两个版本解决了这个问题，一个是32位的，一个是64位的。 GAC可以将它们存储起来，由AssemblyName.ProcessorArchitecture属性解析。这个属性的'normal'设置是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，因此不再有任何警告。用于创建它们的工具很有趣，不幸的是，微软并没有与我们分享。

Fwiw，明确定位x64几乎总是做错事情。它只对EXE程序集很重要，因为它决定了进程的位数。 DLL程序集没有选择，它们的适当构建设置是任何CPU，因此它们可以同时工作。罕见的例外情况是该DLL对非托管组件（通常是COM服务器）具有已知的依赖关系。这些组件通常仅以32位图像的形式提供，当您试图在64位进程中加载​​它们时（“未注册的类”），您很难诊断错误消息。通过迫使他们瞄准x86，你会很难诊断异常，这可能在眼睛上更容易一些，BadImageFormatException。依赖于只能在64位代码中使用的非托管代码非常少见，因此定位到x64没有太大意义。