Что должно идти в MSBuild Script, кроме компиляции? - PullRequest
Новая
       12

Что должно идти в MSBuild Script, кроме компиляции?

3 голосов
/ 04 марта 2009

Я сейчас пытаюсь настроить CruiseControl.net, и поэтому мне интересно, как разделить мои задачи.

Как правило, я хочу запустить модульные тесты (xUnit.net), создание файла справки (Sandcastle) и FxCop.

Теперь мне просто интересно, должен ли я указать новую цель в конфигурации msbuild («Документация») и использовать ее для запуска SandCastle, или она принадлежит отдельному сценарию? Кроме того, msbuild предназначен для сборки чего-либо, так что я думаю, что ncover, xunit и FxCop не должны быть частью этого, или они должны?

Какова область действия msbuild?

Ответы [ 2 ]

6 голосов
/ 05 марта 2009

Поместите почти все в скрипты MSBuild, чтобы вы и другие разработчики могли выполнять те же шаги локально через командную строку. В противном случае, когда что-то пойдет не так со сборкой, вы должны отладить ее на сервере CC. Не хороший опыт отладки. Кроме того, вы хотите запустить сборку локально до , чтобы убедиться, что она работает.

Несколько вещей, которые я бы не включил в сценарии MSBuild:

  • Обновление SVN, так как CC должен делать это в любом случае, и вы обычно не хотите обновляться при локальной сборке. (Ну, я делаю , печатаю svn up && msbuild довольно часто, но это так мало, что мне не нужно помещать это в сценарий.)
  • Создание и публикация отчетов о сборке; опять же это домен CC, а не полезный локально

Что касается структурирования ваших файлов MSBuild, вам понадобится «основной» сценарий сборки, который вы можете использовать для построения всего или только некоторых целей, например

  • MSBuild /t:Build для постепенного создания кода
  • MSBuild /t:Rebuild для чистого восстановления
  • MSBuild /t:UnitTest, чтобы просто запустить модульные тесты
  • MSBuild для наиболее частого выбора, скажем, эквивалентного t:Build;UnitTest
  • MSBuild /t:All для аккуратной сборки кода, документации и настройки, запуска всех тестов и упаковки результатов

Вы также можете добавить «горячие» цели для популярных вариантов.

Наличие одного основного файла сборки не означает, что все определено в этом одном файле; Вы можете включить другие файлы msbuild и / или рекурсивно вызвать msbuild для организации вашей сборки. Например:

  • Основной файл .proj должен быть относительно простым; главным образом, он должен определять специфичные для проекта вещи, такие как список решений для построения и специфичные для проекта переопределения
  • Пусть мастер-файл включает один файл .targets, который содержит цели и свойства по умолчанию; стремиться сохранить этот проект нейтральным и многоразовым.
  • Если файл .targets становится слишком большим, разбейте его на отдельные файлы, например, один для кода, один для справки и документации, один для настройки и упаковки. Пусть ваш основной файл .targets включает эти вложенные файлы, так что вашему файлу .proj по-прежнему нужно включать только один файл
  • Аналогичным образом вы можете разделить основной файл .proj, если это необходимо, например, по подсистеме.
2 голосов
/ 04 марта 2009

У меня есть сценарий сборки для отдельных проектов, и я просто объединяю их в цепочку из второго файла сборки при создании пакета ... например, мой файл сборки protobuf-net обрабатывает управление версиями (SVN), компиляция (MSBuild + NAnt для моно), тестирование (NUnit), упаковка (zip) и т. д. Это ваш процесс сборки; делать то, что вам нужно ;-p Если бы я мог, например, сделать развертывание и документацию, если я хотел.

Это также зависит от того, как вы работаете; если вы используете CruiseControl, он может решить большую часть этого для вас. Для себя мне нравится командная строка "build" step.

...