MSBUILD / csc: Cleanest way of handling x64 mscorlib warning 1607

Question

I'm trying to use VS08SP1's default project system to invoke a C# compile in explicit x64 mode (as distinct from AnyCpu). When I explicitly mark a module as x64, I get a:

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

One way of removing that is with a /nowarn:1607. Based on my research, there are no problems in practice with doing this. If anyone can hilight a real-world issue they've encountered, please feel free to answer.

However, this just feels wrong! So another approach I used was to do /nostdlib+, and then add a <Reference> with a hardcoded <HintPath> to the explicitly 64 bit mscorlib:

<Reference Include="mscorlib">
  <HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath>
</Reference>

This works and is probably better (unless anyone cares to point out reasons why the previous approach is better), but can someone confirm this is an appropriate thing to do, hopefully citing something authorative?

Answer 1

In this blog I found a proposal that is too long to copy it entirely over here, but in short the idea can be described with summary adapted from this comment:

In the project file, you can define a custom variable in the PropertyGroup section for each build configuration. Example:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
    <MyCustomPath>C:\Windows\Microsoft.NET\Framework64</MyCustomPath>
</PropertyGroup>

Just add a tag such as

<Reference Include="System.Data">
    <HintPath>$(MyCustomPath)</HintPath> 
</Reference>

and then use the macro to define the reference path. You can define MyCustomPath to a different location for different build configurations (platform and/or debug/release).
The problem would not exist if MS would support this in the VS UI, but until then this will work. I use this technique to reference different versions of the same assemblies in my debug & release builds. Works great!

In the above recitation I recovered the tag that was lost in the source commentarium and changed the wording to be somewhat more detailed.

An additional interesting piece from the same blog:

There’s some other ways to do this but they also require one to manually edit the project files. One way is to specify conditions to PropertyGroup-sections. This StackOverflow question highlights the use of conditions.

Answer 2

I found by changing my project's Target framework to .NET Framework 4 it eliminated the warning.

Answer 3

I believe your second option (explicit reference with /nostdlib+) is better, because it will not suppress this warning if you were to reference other assemblies not built on the same platform.