我正在尝试使用MSBUILD从命令行清理并重建包含多个项目的解决方案文件。由于某种原因，我的构建失败（大约10％的构建项目失败），我得到多个错误，看起来像：
错误CS0234：类型或命名空间名称＆＃39; foo＆＃39;在命名空间中不存在＆＃39; bar＆＃39; （你错过了一个程序集引用吗？）
现在，如果我使用完全相同的配置从Visual Studio 2010中清理和重建相同的解决方案文件，它将成功构建且没有错误。
我不知道需要更改的Visual Studio中MSBuild的设置或配置是否存在差异？
答案 0 :(得分：3)
我只是不得不处理这个问题，事实证明msbuild喜欢将构建的二进制文件移动到二进制文件\ release目录中，并在构建内容时引用它们而不是项目本身。构建之后，将文件复制到此目录。这解释了为什么它在visual studio中工作而不是msbuild（我目前正在使用TFS 1010）。
在我的情况下，我有一个旧的二进制版本的dll被一个项目引用，该项目是在应该生成正确文件的项目之后构建的。旧的（二进制）覆盖了新的（二进制），因为引用二进制的解决方案正在构建中稍后构建。
答案 1 :(得分：2)
我认为项目的构建方式存在差异，因为Visual Studio不运行MSBuild，因为它主要承载构建引擎本身。 回答here。
但是，我遇到了类似的问题。
在我的例子中，该项目引用了一个外部库，该库被放置在项目的子目录中，不幸的是名为“packages”。
运行MSBuild后，文件夹的内容被删除，据说Nuget会再次下载。
显而易见的解决方案是重命名文件夹并且有效。
答案 2 :(得分：1)
尝试检查MSBuild在非构建库的项目文件中找不到的引用的路径。有时当您使用VS或ReSharper为您自动添加引用时，路径最终会到达\ obj目录。 VS似乎能够应付这一点，但MSBuild并没有那么多。
答案 3 :(得分：1)
对我来说，问题是解决方案中的某些项目未包含在解决方案的构建配置中。这些项目是构建配置中项目的依赖项，因此解决方案中的所有项目都失败了。
在解决方案配置中使用build标记dependcies项目后，msbuild成功运行。
答案 4 :(得分：0)
在我的情况下，我有一个PCL引用另一个具有不同目标的PCL。 Visual Studio在第一个库的引用列表中向我显示了警告，但编译了解决方案，而MSBUILD拒绝编译。我通过重新定位PCL来解决问题。希望这有助于某人。
答案 5 :(得分：0)
摘要：将Visual Studio中的调试/发布模式设置为与MSBuild相同的设置，以检查编译错误。
我遇到了同样的问题：
尝试删除所有“ bin”和“ obj”文件夹。
确保所有相关项目确实得到引用，而不仅仅是喜欢编译的dll。例如项目B参考A。从解决方案中删除A。然后再次添加。然后，B将引用A，但仅通过编译的dll。删除引用并重新添加项目。
最后在Visual Studio中切换为“发布”。原来我在某些代码中有条件编译（例如#if DEBUG）。因此，在MSBuild和Visual Studio中运行的实际上是不同的，因此错误“类型或名称空间名称'foo'在名称空间'bar'中不存在（您是否缺少程序集引用？）“
答案 6 :(得分：0)
我的问题在解决方案文件中找到。
删除所有引用CPU的“ ANY”行，并将64位保留在其中。
答案 7 :(得分：0)
查看我的回答here。
基本上 - 尝试每次在新的 cmd 窗口中运行 msbuild 作为临时解决方法。