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?

I am encountering the same issue. Would be interested in the solution. Thanks. — decasteljau, Oct 06 '09 at 14:13

score 9 · Answer 1 · edited May 23 '17 at 12:00

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.

+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) — Ruben Bartelink, Feb 04 '12 at 08:37

score 6 · Accepted Answer · answered Apr 13 '11 at 17:47

6

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

answered Apr 13 '11 at 17:47

Todd H.

2,522
1
18
9

3

+1 But moving to a different CLR and VS is cheating :P (Serioulsy, thanks for taking the time to answer) – Ruben Bartelink May 03 '11 at 23:42
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... – Ruben Bartelink Feb 04 '12 at 08:39
2

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. – xxbbcc Oct 31 '12 at 15:27
4

Doesn't work for me. I targeted the .NET framework V4.0 and I still get the warning. – C.J. Oct 29 '13 at 21:25
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. – Jay Imerman Aug 29 '14 at 14:18
This answer to a similar question explains why the warning occurs and how .NET 4 fixed the issue. http://stackoverflow.com/a/4077901/54289 – EnocNRoll - AnandaGopal Pardue Mar 04 '15 at 18:26

score 3 · Answer 3 · edited Nov 04 '10 at 23:55

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.

edited Nov 04 '10 at 23:55

Ruben Bartelink

59,778
26
187
249

answered Nov 03 '10 at 16:08

Peter T. LaComb Jr.

2,935
2
29
44

+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 – Ruben Bartelink Nov 04 '10 at 23:59
1

I can't think of any downsides unless you are compiling on an x86 box that might not have the assembly at that path. – Peter T. LaComb Jr. Nov 05 '10 at 14:02
as far as msbuild is concerned (really team build), my preference would be to run each platform build on that platform. – Peter T. LaComb Jr. Nov 05 '10 at 14:03

score 1 · Answer 4 · answered Aug 29 '14 at 14:23

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.

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

4 Answers4