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?

Bucovina

I am encountering the same issue. Would be interested in the solution. Thanks. – Micky

Answer 1

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

Mcdevitt

+1 But moving to a different CLR and VS is cheating :P (Serioulsy, thanks for taking the time to answer) – Bucovina

Finally accepting - While this doesnt answer the actual question, this is the solution I actually ended up using, and I guess it's pretty much the idiomatic 'answer' in this ecosystem... – Bucovina

This is not a solution to the problem in any way. It may have worked for you Todd, but many projects cannot be simply changed to target a different framework. – Marchpane

Doesn't work for me. I targeted the .NET framework V4.0 and I still get the warning. – Colloid

Another problem with this approach, is .NET 4 is not always a solution. We are building a project that may be deployed in multiple customers environments, and we have no control over whether they have 4 or not. Our experience is, 4 also sometimes causes issues with other enterprise software, and so it may not be an option for those customers. – Electrophilic

This answer to a similar question explains why the warning occurs and how .NET 4 fixed the issue. https://mcmap.net/q/393892/-cs1607-compiler-warning-when-building-the-x64-version – Charged

Answer 2

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.

Hassanhassell

+1 In my scenario, I don't actually need this tecnique - I always want x64. Still leaving the question unaccepted - I'd like to know what Microsoft would recommend as a way of handling a built in error (without having to tolerate their horrible forum software :P) – Bucovina

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.

Anecdotal

+1 insightful (First read I wasn't sure). I'll hold off on accepting to hang onto my choosy rating :P (Seriously: I'm interested in hearing any negatives of my second approach - you'd think it'd be defaulted by VS if there are no downsides). However I guess from an msbuild perspective, it makes lots of sense, and csc shouldn't be having all this policy built directly into the tool – Bucovina

I can't think of any downsides unless you are compiling on an x86 box that might not have the assembly at that path. – Anecdotal

as far as msbuild is concerned (really team build), my preference would be to run each platform build on that platform. – Anecdotal

Answer 4

In my case, I had this warning because I had a mix of x86 and x64 projects in my solution. If I create x86 build configurations in all my projects, and target that for the build, the warnings go away. However, if I wanted to target x64 in all, I believe I would have to rebuild the project (or follow advice above) to rework them for x64 framework.

Electrophilic