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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 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>

Замените проекты вашими проектами, и группа должна быть имитирована для цели "Очистить".

Я хочу, чтобы было лучшее решение, и я не знаю, почему команда MSBuild не добавит эту функцию в продукт. Как вы сказали, сделайте это несколько десятилетий назад. FWIW, я не знаю, насколько хорошо это работает со сложными зависимостями построения и построением parallelism.

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

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

Ответ 3

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

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

Ответ 4

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