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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Создайте свой собственный файл msbuild proj и вызовите csproj (или sln) из основного файла сборки через задачу msbuild. Скажите вашему CI-серверу, чтобы он собрал ваш файл сборки.

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

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

Answer 3

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

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

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

Answer 4

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

Примечания:

1. Если вы используете Windows Workflow Основой в своих проектах вы будете есть большие трудности построить такой проект без msbuild.
2. Не устанавливайте VS.NET на сборочной машине. Вы можете использовать Wix сделать MSI установки.
3. @ Франци Пенов: Запуск юнит-тестов ДОЛЖЕН быть частью каждой сборки. Вы действительно хотите подождать до завтра, чтобы найти ошибку? Есть примечание: юнит-тесты должны выполняться очень быстро.

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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