CS1607 compiler warning when building the x64 version

Question

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

Answer 1

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.