当某些内容无法编译时,使Visual Studio(Express)停止编译

Question

如果一个项目无法构建,默认情况下,Visual Studio 会继续尝试构建依赖于该项目的所有其他项目,因此会产生愚蠢的错误,因为这些其他项目现在正在构建二进制版本的旧版本.

我怎样才能改变这种行为,让它在失败时停止？

例如,假设我有一个名为MyApp.Core的库项目,以及一个名为MyApp的可执行项目.MyApp在MyApp.Core中调用一个方法.假设我向该方法添加了一个新参数,然后尝试构建,但是我无意中在MyApp.Core中引入了一个不相关的编译器错误.当我构建时,Visual Studio将:

• 尝试构建MyApp.Core,并因编译器错误而失败.磁盘上的MyApp.Core.dll保持不变,因为构建失败.
• 继续尝试针对旧版本的MyApp.Core.dll构建MyApp,并报告编译器错误,因为它传递的参数多于旧DLL期望的方法.
• 在" 错误"窗口的顶部报告第二批错误,从而很难找到实际问题.

自1977年以来,Make已经解决了这个问题:当它意识到它无法构建时,就会停止构建.我使用的每个其他构建系统和IDE也足够聪明,可以阻止丢失的原因.但Visual Studio并没有完全赶上1977年的技术复杂性.

" Visual Studio Hacks " 一书在其宏部分中有一个解决方法:您可以编写一个宏,在项目完成构建时触发; 如果项目的构建状态为"失败",则宏可以发出"取消构建"命令.我经常在我使用Visual Studio的每台计算机上安装此hack.但是,在家里我使用Visual C#Express,它不支持宏.

有没有办法让Visual Studio 2010(包括Express版本)停止构建失败？

Answer 1

尽管我很喜欢 MSBuild，但在使用解决方案文件进行构建时没有内置的方法来执行此操作（正如您已经发现的那样）。启用 Resharper 的分析后，我发现现在编译器错误对我来说非常罕见，因此我很少遇到错误消息过多的问题。

在我以前的商店中，有人经常对构建进行修改，以便将根项目之一包含在 60 多个项目的解决方案中，因此，许多人开始从命令行单独运行项目，类似于运行单独的 Make 文件。

如果您确实想以与您提到的宏不同的方式处理此问题，您可以构造一个外部 msbuild 文件，该文件单独执行项目并检查运行之间的错误。您必须保持构建顺序正确，并且需要从命令行运行它和/或添加“工具”菜单选项的快捷方式。

这是一个例子：

 <?xml version="1.0" encoding="utf-8"?>
 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Build">
     <MSBuild ContinueOnError="false" Projects="log4net\log4net.csproj" Targets="Build">
          <Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
     </MSBuild>
     <MSBuild ContinueOnError="false" Projects="Project1\Project1.csproj" Targets="Build">
          <Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
     </MSBuild>
     <MSBuild ContinueOnError="false" Projects="Project3\Project3.csproj" Targets="Build">
          <Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
     </MSBuild>
    </Target>
   <!-- <OnError ExecuteTargets="ErrorTarget" /> //-->
  </Project>

将项目替换为您的项目，并且需要模仿该组以实现 Clean 目标。

我希望有更好的解决方案，但我不知道为什么 MSBuild 团队不将此功能添加到产品中。就像你说的，Make 几十年前就想出来了。FWIW，我不知道这对于复杂的构建依赖关系和构建并行性的效果如何。

我对 MSBuild 的问题集中在 ResolveAssemblyReferences 和 ResolveComReferences 任务上，它们是具有大型/复杂项目依赖树（大型至少相对约 30 个项目）的大型解决方案中构建最慢的部分。

我希望这有帮助。