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 был обновлен с помощью Нант - контрибьютор так что я получил msbuild такс.Возможно, это временная настройка, но пока у меня не возникало серьезных проблем.Тем не менее, я также не создаю новый файл csproj, потому что я использую тот же csproj / sln, который я использую в VS2008.Создание проектов с помощью msbuild значительно упростило устаревшие скрипты NAnt (мы использовали csc задание).

Примечания:

1. Если вы используете Windows Workflow Foundation в своих проектах, у вас будут серьезные трудности при создании такого проекта без msbuild.
2. Не устанавливайте VS.NET на свой компьютер сборки.Вы можете использовать Викс сделайте создание установочного 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.