MSBuild fails where VS2010/2013 succeeded - Mixed 3.5 and 4.0 - Why?

Question

I have the following situation at work and wanted to hear some advice as i'm pretty much out of ideas and going out of my mind.

I have a solution that contains our server-side projects - Some Web Applications to be deployed to IIS and a couple of class libraries with logic. It was originally made (as far as i know) in VS2010 under .NET 3.5. The solution was upgraded over time and now contains some projects that are targeting .NET 4.0 as well.

The solution builds and works as expected in run-time with VS2010 and VS2013 (which I'm mostly using now) on my machine - a 32-bit Windows 7 SP1 machine with a full VS2013 install, etc. The solution also builds perfectly through usage of command line MSBuild on my machine (so 32 bit).

When built from our 64-bit TFS 2010 server, The build fails citing indirect references from a .NET 3.5 assembly to .NET 4.0 base assemblies like mscorlib, etc.

The client-side solution (with a WPF 'shell' and more class library logic projects), as well as the shared projects among both, are all .NET 3.5 and all build well on both my machine and the TFS server.

What I've noticed so far after reading THIS is that the build order on the TFS server is different. I tried the workarounds for the main/first issue mentioned, but none helped so far. Haven't tried the second (compiling forcibly on 32-bit or to the affect as mentioned), But i'm going to.

Either way, Here are the server solution build orders simplified and named to what i thought would explain what's going on.

VS2010/VS2013:

1. Common.csproj // .NET 3.5 Shared/common code between 'client' and 'server' solutions.
2. Server.Common.csproj // .NET 4.0 Server-side projects only shared/common code. References Common.
3. Client.Common.csproj // .NET 3.5 Client-side projects only shared/common code. References Common.
4. Server.DomainModels.csproj // .NET 4.0 Server side class library. References Server.Common and Common.
5. Agents.csproj // .NET 3.5 Client side class library, used to call the server-side Web Application projects, A proxy of sorts. References Client.Common and Common.

This order builds correctly.

However, When running on the aforementioned TFS2010 Server build i get this order instead:

1. Server.DomainModels.csproj (which was #4 above) -> 1. Common.csproj (invoked to satisfy the reference by the above). -> 2. Server.Common.csproj (also invoked to satisfy the reference above).
2. 'Proper/Original' ordered Common.csproj (already built above, #1 before)
3. 'Proper/Original' ordered Server.Common.csproj (already built above, #2 before)
4. Agents.csproj (#5 before) -> 1. Client.Common.csproj (#3 before and was built before #5 in the original order)

The Client.Common.csproj project (.NET 3.5) fails to build because it can't satisfy its reference for Common.csproj (who is presumably Targeting .NET 3.5) because apparently it now has indirect references to .NET 4.0 assemblies - as it was built to satisfy the reference for the Server.DomainModels.csproj project (.NET 4.0).

This doesn't make sense to me, But it seems to be what happens. I'd appreciate any advice or suggestions to check/change regarding this issue.

Thank you in advance.

Answer 1

So, i went over the linked blog article again, and this time the comments as well. One comment refers to that msbuild still looked at the order defined by the solution rather than what the article illustrates.

I tried it, moving Common and Server.Common to the top - eureka! It now builds properly on tfs' msbuild.

Some of my transforms still fail only when running through tfs, but at least im closer to getting it done.