When you build 64-bit .NET applications with Visual Studio, the Assembly Linker issues warning messages of the form:
Assembly mscorlib.dll targets a different processor.
It will issue that warning for each of the .NET runtime assemblies that your project references. The warning occurs because the linker checks the 32-bit runtime assemblies for type information, and since you’re building a 64-bit assembly, there’s a mismatch. The documentation says that it’s safe to ignore this warning because all of the .NET assemblies are guaranteed to have the same external interface, regardless of the CPU for which they are compiled. Specifically, the documentation says:
All x86-specific common language runtime (CLR) assemblies have 64-bit counterparts (every CLR assembly will exist on all platforms). Therefore, you can safely ignore CS1607 for CLR assemblies.
And that does appear to be the case. There is no conflict when you run the application.
I contend, however, that this is a bug in the tool. Why? Because it is a spurious warning that I can’t safely eliminate. And why can’t I safely eliminate it? I’m so glad you asked.
I can eliminate the warning. All I have to do is go into the project properties and add ‘1607’ to the list of warnings I want disabled. Goodbye, warning. But doing that eliminates all occurrences of the warning in the project. If I just happen to have a conflict within my own solution (i.e. trying to link my 64-bit project with a 32-bit assembly that I created), I won’t see the warning. And I’ll get a rude shock when I deploy and try to run the resulting application.
In addition, Visual Studio 2008 will issue the same warning number (CS1607) if the AssemblyVersionInfo attribute in your AssemblyInfo.cs file is not in the recommended format. That in itself is a spurious warning in my opinion, and one that I’d love to disable. Except that if I disable it, I also disable the processor mismatch warning.
You might wonder why I even worry about it, if the warnings are ignorable. There are two reasons. First, when a solution I’m building in Visual Studio issues warnings, I have to examine each warning to make sure that I can safely ignore it. Some of my solutions have more than 20 different projects–tools and dependent assemblies. If each one issues a warning about every referenced CLR assembly targeting a different processor, I have almost 50 warnings to wade through for each build. The risk of missing a real warning in that mess of useless messages is very high.
More importantly, we’re trying to put together an automated build system. In automated builds, warnings should be treated as errors. Otherwise you have to write some kind of post-processing filter that can examine the tool output to determine whether the warnings are meaningful. Doing so introduces yet another uncertainty into the process: the correctness of the post-processing tool and any configuration file that controls it.
So I’m left with no good solution. Whether I enable or disable the the spurious warnings, there’s a very real possibility of missing an important warning. I could understand this bug existing in Visual Studio 2005, but the development team has had more than two years to work out a solution. There is no excuse for the bug remaining in Visual Studio 2008 and the latest version of the .NET tools. Rather than fixing it, they made the problem worse by overloading the warning number. That’s unforgivable.