MSBuild 使用项目引用正确构建项目，但不是来自解决方案答案

【问题标题】：MSBuild builds projects with project references correctly but not from solutionMSBuild 使用项目引用正确构建项目，但不是来自解决方案
【发布时间】：2010-11-03 07:54:14
【问题描述】：

当我构建一个包含 2 个项目 B.csproj 和 C.csproj 的 A.sln 时，它具有内部项目引用，它会在 MSBuild 中引发引用错误。但是当我在 MSBuild 中分别构建 B.csproj 和 C.csproj 时，它不会抛出错误。而且在 VS IDE 中构建 A.sln 也不会抛出错误。我使用的是 .NET 2.0 框架。请在下面找到用于构建 sln 和 projs 的脚本。

MSBuild "<path>/A.sln" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\A.sln.log /verbosity:normal

MSBuild "<path>/B.csproj" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\B.csproj.log /verbosity:normal 

MSBuild "<path>/C.csproj" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\C.csproj.log /verbosity:normal

编辑：

所有抛出的错误都来自缺少引用的代码（都是项目引用）。我只收到三种类型的错误，如下所示。

错误 CS0012：定义了类型“X” 在未引用的程序集中。您必须添加对程序集的引用 'Y，版本=2.0.0.0，文化=中性， PublicKeyToken=aad4cbe5d7c27078'。

错误 CS0234：类型或命名空间名称“X”不存在于命名空间“Y”（您是否缺少汇编参考？）

错误 CS0246：类型或命名空间找不到名称“X”（您是缺少 using 指令或汇编参考？）

在从 IDE 和 MSBuild 构建之前，我从构建路径中清除了所有以前构建的 dll。但是 IDE 工作正常，并且不会在项目的“参考”部分显示参考缺失指示器。

没有在 IDE 中手动添加参考路径。

另一个更新：

我刚刚注意到，当我从解决方案打开两个项目时，引用正确指向 IDE。但是当我在 IDE 中单独打开项目时，我提到的在 MSBuild 中出现的缺失引用会逐渐增加。很奇怪。

总结一下，

在 MSBuild 中构建 .proj - 好

在 IDE 中构建 .proj - 错误

在 MSBuild 中构建 .sln - 错误

在 IDE 中构建 .sln - 好

对我来说看起来很奇怪。非常感谢您的帮助。

【问题讨论】：

每当您提出问题并说有错误时，剪切和粘贴错误确实很有帮助。这适用于异常、编译器错误、构建错误...
顺便说一句，如果它单独构建两个项目没有问题，那么我想知道这两个项目是否需要项目引用。 OTOH，这可能是由于最近的功能允许 MSBUILD 对项目引用“聪明”。因为我从来没有理解过这个功能，所以我不能排除它；但我建议您确认是否需要所有项目引用，以及重建 B 是否会导致重建 C。
@blntechie：感谢您的更新。我建议您使用解决方案资源管理器；按顺序选择每个引用，然后在“属性”窗口中查看详细信息。看到任何奇怪的东西，比如一个在 obj 中，而另一个在 bin 中？此外，如果没有参考路径，那么您可能不介意查看您的 .csproj.user 文件以确保确实没有？
@John Saunders：感谢您的帮助。我刚刚注意到，当我从解决方案打开两个项目时，引用正确指向 IDE。但是当我在 IDE 中单独打开项目时，我提到的在 MSBuild 中出现的缺失引用会逐渐增加。很奇怪。非常感谢您的帮助。也更新问题。
你是怎么解决这个问题的？我也有同样的经历……

标签： .net msbuild

【解决方案1】：

MSBuild 和 VS 都使用项目引用和项目依赖项来选择解决方案构建顺序。除此之外，它是未定义的 - 并且两者之间通常不同。检查这两个是否正确。项目依赖项在解决方案的属性中设置。如果这不起作用，请仔细检查项目中项目引用中的 GUID 是否与解决方案中的 GUID 匹配。有时重新创建解决方案可以修复它们。

【讨论】：

【解决方案2】：

对我来说，当我遇到这个（或类似的）问题时，手动检查（并修复）guid 队列可以解决我的问题。跟踪 .sln 和 .csproj 文件之间的 guid 很烦人，但它确实有效。

我通常会删除项目引用并重新添加它，这样就可以解决问题（一旦我发现有问题的不匹配的 guid）。也许我应该先尝试一下。这更容易。

【讨论】：

同样的事情对我有用。我发现找出哪些 GUID 未对齐的最佳方法是将 Visual Studio 排除在外，并尝试纯粹使用 MSBuild 构建，这会使错误浮出水面。请参阅这篇文章了解如何做到这一点：codeproject.com/Tips/177770/…

【解决方案3】：

需要考虑的一些事项：在 IDE 中构建解决方案与在 .sln 文件上运行 MSBUILD 不同。您可以尝试改用 devenv.exe /rebuild A.sln。 IDE 会玩多个游戏以允许构建 .sln 文件，包括创建“等效”MSBUILD 样式的项目。

此外，IDE 并不直接生成 MSBUILD 命令。两者之间存在交互以提高性能。例如，项目中的 CSC 任务可能在 IDE 内执行，而不是作为单独的命令行构建，因为 MSBUILD 会产生它们。

您还应该考虑从http://technet.microsoft.com/sysinternals/ 获取进程监视器，以查看正在访问哪些文件。

【讨论】：

【解决方案4】：

正如 Jon Skeet 所提到的，错误消息有助于了解问题所在。但是，如果没有任何详细信息，如果它在 IDE 中构建但未在 MSBuild 中构建，听起来您可能在项目中引用了在构建解决方案的路径中不可用的 DLL。也许您手动将它们复制到 IDE 可以找到它们的位置，或者您在 IDE 中设置了参考路径以查看某个文件夹。

只是在您了解问题的其他详细信息时要检查的内容。

编辑： 现在有一些细节，可能是构建顺序问题。项目 B 中是否有项目 C 的项目引用？如果是这样，您可能只需要在项目 B 之前更改构建项目 C 的顺序。

【讨论】：

在我的例子中，Proj C 引用了 Proj B。Proj B 在 Proj C 之前构建。

【解决方案5】：

从 GAC 中删除程序集（C:\WINDOWS\assembly 文件夹 - 选择您的程序集并右键单击并卸载）。

因为解决方案使用 guid 保持引用，如果该 guid 在 GAC 中，它将继续使用 GAC 版本进行编译。

【讨论】：