我在工作中遇到以下情况，想听听一些建议，因为我几乎没有想法，并且不知所措。MSBuild失败VS2010/2013成功 - 混合3.5和4.0 - 为什么？
我有一个解决方案，其中包含我们的服务器端项目 - 一些Web应用程序被部署到IIS和一些类库的逻辑。它最初是在.NET 3.5的VS2010下制作的（据我所知）。该解决方案随着时间的推移而升级，现在还包含一些针对.NET 4.0的项目。
该解决方案在我的机器上使用VS2010和VS2013（我现在主要使用它）在运行时按预期构建和运行 - 具有完整VS2013安装的32位Windows 7 SP1机器等。解决方案也可以通过在我的机器上使用命令行MSBuild完成构建（所以32位）。
当从我们的64位TFS 2010服务器建立，生成失败援引从.NET 3.5组件间接引用到.NET 4.0底座组件等mscorlib程序等
的客户端解决方案（具有WPF'外壳'和更多类库逻辑项目）以及两者之间的共享项目，都是.NET 3.5，并且都可以在我的机器和TFS服务器上很好地构建。
在阅读THIS之后到目前为止，我注意到TFS服务器上的构建顺序是不同的。我尝试了所提到的主要/第一个问题的解决方法，但目前为止没有任何帮助。没有尝试第二个（强制编译32位或上述影响），但我要去。
无论哪种方式，下面是服务器解决方案构建命令的简化和命名，我想解释发生了什么。
VS2010/VS2013：
- Common.csproj // .NET 3.5共享/公共 '客户' 和 '服务器' 的解决方案之间的代码。
- Server.Common.csproj // .NET 4.0服务器端项目只有共享/通用代码。常用参考。
- Client.Common.csproj // .NET 3.5客户端项目只有共享/通用代码。常用参考。
- Server.DomainModels.csproj // .NET 4.0服务器端类库。参考Server.Common和Common。
- Agents.csproj // .NET 3.5客户端类库，用于调用服务器端Web应用程序项目，各种代理。参考Client.Common和Common。
此订单构建正确。
然而，当在上述TFS2010服务器构建运行我得到这个顺序代替：
- Server.DomainModels.csproj（这是上述＃4） - > 1. Common.csproj（调用，以满足上面的参考）。 - > 2. Server.Common.csproj（也被调用以满足上面的参考）。
- '正确/原始' 有序Common.csproj（上文已建成，＃1之前）
- '正确/原始' 有序Server.Common.csproj（上文已建成，＃2之前）
- Agents.csproj （＃5之前） - > 1. Client.Common。的csproj（＃3前，按照原来的顺序＃5之前建）
的Client.Common.csproj项目（.NET 3.5）构建失败，因为它不能满足其对参考Common.csproj（谁可能是目标.NET 3.5），因为它显然现在间接引用了.NET 4.0程序集 - 因为它的构建是为了满足Server.DomainModels.csproj项目（.NET 4.0）的参考。
这对我来说没有意义，但它似乎是发生了什么。 我很感激任何意见或建议来检查/更改有关此问题。
预先感谢您。
是的，没什么，我想要更多关于这一点。可悲的是，这需要一些重要的工作日来升级一些第三方/内部库和代码重新分解我们现在无法做到。 –
预计很多，但不得不尝试... – AlonEl