我正在尝试使用 MSBUILD 从命令行清理和重建包含多个项目的解决方案文件。由于某种原因，我的构建失败（大约 10% 的构建项目失败）并且出现多个错误，看起来都像：
错误 CS0234：命名空间“bar”中不存在类型或命名空间名称“foo”（您是否缺少程序集引用？）
现在，如果我使用完全相同的配置从 Visual Studio 2010 清理并重建相同的解决方案文件，它将成功构建而不会出现错误。
Visual Studio 的 MSBuild 设置或配置是否存在我不知道的需要更改的差异？
【问题讨论】：
标签： visual-studio-2010 visual-studio msbuild
尝试检查 MSBuild 在非构建库的项目文件中找不到的引用的路径。有时，当您使用 VS 或 ReSharper 自动为您添加引用时，路径最终会指向 \obj 目录。 VS 似乎能够应付这一点，但 MSBuild 没有那么多。
【讨论】：
我只需要处理这个问题，结果发现 msbuild 喜欢将构建的二进制文件移动到 binaries\release 目录中，并在构建内容时引用这些文件而不是项目本身。构建后将文件复制到此目录。这解释了为什么它在 Visual Studio 而不是 msbuild 中工作（我目前正在使用 TFS 1010）。
在我的情况下，我有一个旧的二进制版本的 dll 被一个项目引用，该项目在应该生成正确文件的项目之后构建。旧的（二进制）正在覆盖新的（从源代码构建），因为引用二进制的解决方案是在构建的后期构建的。
【讨论】：
在我的例子中，我有一个 PCL 引用另一个具有不同目标的 PCL。 Visual Studio 在第一个库的引用列表中向我显示了警告，但编译了解决方案，而 MSBUILD 拒绝编译。我通过重新定位 PCL 解决了这个问题。希望这对某人有所帮助。
【讨论】：
我假设项目的构建方式有所不同，因为 Visual Studio 不运行 MSBuild，而是托管构建引擎本身。 这是here的回答。
不过，我也遇到过类似的问题。
在我的例子中，项目引用了一个外部库，该库被放置在项目的子目录中，不幸地命名为“packages”。
运行MSBuild后文件夹的内容被删除了，应该是Nuget重新下载的。
显而易见的解决方案是重命名该文件夹，并且成功了。
【讨论】：
对我来说，问题是解决方案中的某些项目未包含在解决方案的构建配置中。这些项目是构建配置中项目的依赖项，因此解决方案中的所有项目都失败了。
在解决方案配置中使用 build 标记依赖项目后，msbuild 运行成功。
【讨论】：
总结：将 Visual Studio 中的 Debug/Release 模式设置为与 MSBuild 相同的设置，以检查编译错误。
我遇到了同样的问题：
尝试删除所有“bin”和“obj”文件夹。
确保确实引用了所有相关项目，而不仅仅是喜欢编译的 dll。前任。项目 B 引用 A。从解决方案中删除 A。然后再添加。然后 B 将引用 A 但仅通过编译的 dll。删除引用并重新添加项目。
终于在 Visual Studio 中切换到“Release”。原来我在一些代码中进行了条件编译（例如#if DEBUG）。因此，在 MSBuild 和 Visual Studio 中运行的内容实际上是不同的，因此出现错误“命名空间 'bar' 中不存在类型或命名空间名称 'foo'（您是否缺少程序集引用？）”
【讨论】：
在解决方案文件中发现了我的问题。
删除所有引用 CPU 'ANY' 的行并保留 64 位的行。
【讨论】：
看我的回答here。
基本上 - 尝试每次都在新的 cmd 窗口中运行 msbuild 作为临时解决方法。
【讨论】：
我遇到了类似的问题。但是花了很多时间，我终于想出了一个解决方案（性能类似于VS）
使用以下命令构建您的解决方案
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”
【讨论】：