Заставить Visual Studio (Express) прекратить компиляцию, когда что-то не компилируется

Question

Если один проект не может быть собран, Visual Studio по умолчанию продолжает пытаться построить все другие проекты, которые зависят от этого проекта, и поэтому получает глупые ошибки, потому что эти другие проекты сейчаспостроение против устаревшей версии двоичного файла.

Как я могу изменить это поведение и заставить его останавливаться при сбое?

Например, предположим, у меня есть проект библиотеки под названием MyApp.Core,и исполняемый проект под названием MyApp.MyApp вызывает метод в MyApp.Core.Предположим, я добавил новый параметр в этот метод, а затем попытался построить, но я случайно ввел несвязанную ошибку компилятора в MyApp.Core.Когда я собираю, Visual Studio будет:

• Попытаться собрать MyApp.Core и потерпеть неудачу из-за ошибки компилятора.MyApp.Core.dll на диске остается неизменным, поскольку сборка не удалась.
• Продолжайте пытаться создать MyApp для этой более старой версии MyApp.Core.dll и сообщать об ошибках компилятора, поскольку он передает больше параметров, чемметод в старой DLL ожидает.
• Сообщите о втором пакете ошибок в top окна Errors, что очень затруднит поиск фактической проблемы.

Make решает эту проблему с 1977 года: когда он понимает, что не может собрать, он прекращает сборку. Любая другая система сборки и IDE, которые я использовалтакже достаточно умен, чтобы остановиться на безнадежном деле.Но Visual Studio не совсем догнал технологическую сложность 1977 года.

Книга " Visual Studio Hacks " в своем разделе о макросах имеет обходной путь: вы можете написатьмакрос, который запускается при завершении проекта;если состояние сборки проекта было «не выполнено», макрос может выдать команду «Отменить сборку».Я регулярно устанавливаю этот хак на каждый компьютер, на котором я использую Visual Studio.Однако дома я использую Visual C # Express, который не поддерживает макросы.

Есть ли способ заставить Visual Studio 2010 (включая редакции Express) остановить сборку при сбое сборки?

Answer 1

Как бы мне ни нравился MSBuild, не существует встроенного способа сделать это при использовании файла решения для сборки (как вы уже обнаружили). С включенным анализом Решарпера я обнаружил, что ошибки компилятора в настоящее время очень редки для меня, поэтому у меня редко возникает проблема с подавляющим количеством сообщений об ошибках.

В моем предыдущем магазине кто-то обычно собирал сборку так, чтобы один из корневых проектов был представлен в более чем 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 не добавит эту функцию в продукт. Как вы сказали, «Разберись с этим десятилетия назад». FWIW, я не знаю, насколько хорошо это работает со сложными зависимостями сборки и параллелизмом сборки.

Мои проблемы с MSBuild сосредоточены вокруг ResolveAssemblyReferences и задач ResolveComReferences, которые являются самой медленной частью сборки в большом решении с большим / сложным деревом зависимостей проекта (большое относительное относительно ~ 30 проектов как минимум).

Надеюсь, это поможет.

Answer 2

Существует также это бесплатное расширение для Visual Studio 2010/2012/2013, которое делает это.

StopOnFirstBuildError (Загрузить)

http://visualstudiogallery.msdn.microsoft.com/91aaa139-5d3c-43a7-b39f-369196a84fa5

Остановить сборку при первой ошибке в Visual Studio 2010 (запись)

http://einaregilsson.com/stop-build-on-first-error-in-visual-studio-2010/

Answer 3

Я всегда просто удерживаю клавишу «Пауза / Прерывание», когда вижу, что это происходит, и это отменяет сборку.

Answer 4

Вы также можете убить процесс под названием cl.exe с помощью диспетчера задач. Может быть несколько cl.exe процессов - достаточно убить только одного из них.

Это немедленно остановит процесс сборки.