MSBuild - Используйте файл .csproj или сверните свой собственный?

ОК, поэтому я с готовностью признаю, что я новичок, когда речь идет о непрерывной интеграции.

Как я уже сказал, я пытаюсь настроить среду CC.NET, чтобы обучать себя, но мне трудно найти информацию, необходимую мне для создания автоматической сборки.

Как я понимаю, в С# файл .csproj, созданный VS 2005, и forward - это допустимый файл MSBuild. Для этого мне удалось интегрировать задачу MSBuild в CC.NET с использованием файла .csproj, но у меня есть несколько проблем с этим:

  • Здесь многое происходит, что я не уверен, что мне действительно нужна автоматическая среда сборки.
  • Я не создавал этот файл. Я этого не понимаю, и это меня пугает. (Программирование по совпадению)
  • Большая часть происходящего, кажется, абстрагируется через $(MSBuildToolsPath)\Microsoft.CSharp.targets
  • В результате 1, 2 и 3, изменение файла, чтобы включить что-то вроде MbUnit, кажется запутанным и сложнее, чем должно быть. Моя единственная реальная опция - включить его в раздел AfterBuild, который кажется вроде как взломать меня.

Итак, несколько вопросов для людей CC.NET, людей MSBuild и людей MbUnit.

  • При использовании MSBuild целесообразно использовать VS-образный файл .csproj в качестве файла сборки? Или я должен создать свой собственный?
  • Должны ли тесты MbUnit быть частью файла MSBuild или файла CC.NET? Мои исследования показывают, что они принадлежат к файлу MSBuild. Если это так, я могу создать новый файл MSBuild.proj и проверить это на CVS в дополнение к файлу .csproj? Или задача MbUnit входит в мой файл .csproj?
  • Как и в вопросе 2. Если я добавлю тесты MbUnit в файл MSBuild и в конечном итоге использую файл .csproj, действительно ли Target Name="AfterBuild" раздел для добавления этой информации? Разве не должно быть раздела Target Name="Test"? Использование созданного VS файла .csproj предотвращает второй вариант.

Я знаю там много, но большинство из того, что я смог найти в Интернете, предполагает определенный уровень знакомости с этими темами, которые у меня просто нет, - если я не ошибаюсь, кривая обучения для этот материал не является кривой вообще, это ступенчатая функция.:)

Изменить 1: я обновил текст, чтобы быть немного более кратким и рассмотрел некоторые затяжные вопросы, которые у меня были с ответами.

ОТВЕТЫ

Ответ 1

Я бы рекомендовал использовать сгенерированные файлы .csproj - на самом деле для производства, я думаю, что использование сгенерированных файлов .sln - хорошая идея. Я обнаружил, что вы сможете получить те же файлы решений, что и разработчики.

Имейте в виду, что .sln файлы фактически не являются действительными файлами проекта msbuild - они преобразуются в проекты msbuild самим msbuild, когда они используются в качестве входных данных. Tricky!

В целях обучения вам может понадобиться зарегистрировать сборку .csproj и выполнить шаг, чтобы получить представление о том, что происходит. MSBuild является немного более декларативным, чем nant, поэтому, не торопитесь и немного экспериментируйте.

Наконец, я бы обернул ваши файлы .sln или .csproj в проект с непрерывной конструкцией script с задачами msbuild для создания ваших проектов и совместной работы с модульными тестами. Таким образом, разработчикам не нужно запускать unit test каждый раз при их создании, но каждый раз, когда они объединяют свой код, будут выполняться модульные тесты. И да, убедитесь, что они бегут быстро! Все, что занимает больше секунды, должно выполняться во время запланированной (ночной?) Сборки. Вероятно, они меньше модульных тестов и больше тестов интеграции, написанных с помощью рамки unit test, если они занимают больше секунды.

Изменить: Некоторая дополнительная информация, которую я нашел полезной - с помощью MSBuild 3.5 вы сможете получить целевой вывод из .sln файла, в то время как эта информация не возвращается в MSBuild 2.0 (хотя я думаю, что он должен работать для файлов .csproj в обеих версиях). Вы можете использовать выходные данные (ваши встроенные файлы) в качестве входных данных для платформы тестирования устройств.

Ответ 2

Оставьте файл csproj в одиночку (как вы говорите, вы его не понимаете).

Создайте свой собственный proj файл msbuild и вызовите csproj (или sln) из основного файла сборки с помощью задачи msbuild. Сообщите серверу CI для сборки файла сборки.

Это разделение упрощает добавление ваших собственных заданий до и после публикации (модульные тесты, тесты тестирования дыма SQL, fxcop/другой статический анализ и т.д.), и вы не нарушаете свою рабочую среду. Это также означает, что вы можете выполнять свои собственные цели в любом желании (msbuild/ ant и т.д.). Посмотрите, как MSBuildContrib на codeplex для дополнительной добра.

Вам не нужен визуальный stuido на вашем сервере сборки (у вас есть проекты развертывания, если только это не изменилось с момента последнего просмотра)

Ответ 3

Создайте свой собственный файл проекта (все, что заканчивается на * proj, считается файлом проекта MSBuild) и вызывается из вашей сборки. Вот так:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Обратите внимание, что msbuild также может создавать .sln(файл решения) без каких-либо изменений, что обычно проще, чем наличие связки файлов csproj...

Ответ 4

Я использую как NAnt, так и MSBuild. NAnt был обновлен NAntContrib, так что я получил msbuild taks. Я могу быть временной установкой, но до сих пор у меня не было серьезных проблем. Тем не менее, я также не создаю новый файл csproj, потому что я использую тот же csproj/sln, который я использую в VS2008. Создание проектов с помощью msbuild значительно упростило устаревшие сценарии NAnt (мы использовали csc).

Примечания:

  • Если вы используете Windows Workflow В ваших проектах вы будете имеют серьезные трудности в проект без msbuild.
  • Не устанавливайте VS.NET на своей машине сборки. Вы можете использовать Wix, чтобы создать установку msi.
  • @Franci Penov: Запуск модульных тестов СЛЕДУЕТ быть частью каждой сборки. Вы действительно хотите подождать до завтра, чтобы найти ошибку? Есть побочная заметка: модульные тесты должны выполняться очень быстро.

Ответ 5

Я лично считаю, что это нормально с файлом .csproj. Там не так много, что вам не придется добавлять себя, если вы запускаете свой собственный проект MSBuild.

Однако, какой бы маршрут вы ни выбрали, я бы порекомендовал не добавлять MbUnit как часть шага сборки, но добавить его как отдельный шаг в CC.Net. Запуск единичных тестов должен быть частью ежедневного цикла CI; однако он не должен быть частью каждой сборки.

Ответ 6

Хорошо использовать .csproj в качестве входа для msbuild. Вы можете вручную добавить задачи для него в csproj, который будет проигнорирован во время усложнения VS. Но если вы собираетесь сделать некоторые нетривиальные вещи, лучше создать отдельные сценарии msbuild. И на них можно ссылаться из файлов csproj. Вы видели MS Build Server, который является частью TFS? Он интегрируется с TFS SourceControl и может использоваться для CI. Его файлами проекта являются скрипты msbuild.

Если я использовал nAnt, требуется ли устанавливать VS на сервере? Возможно, вы имели в виду 'MSBuild'? Нет, не обязательно устанавливать VS для использования msbuild с файлами csproj.

Ответ 7

Хорошо, немного вещей, на которые нужно следить. Формат csproj изменился с VS2005 на VS2008. Также, если вы собираетесь с MSBuild, помните, что вы не сможете создавать файлы .vdproj(setup); для этого вам нужно devenv (исполняемый файл VS). Тем не менее вы всегда можете создать задачу MSBuild, которая вызывает devenv и создает ее для вас.

Что касается вашего вопроса, следует ли создавать собственный файл csproj или использовать тот, который был создан VS2005, я бы предложил среднюю дорогу: создать свой собственный шаблон проекта, который удовлетворяет ваши потребности и позволяет VS заботиться обо всем остальном.