Как перейти на автоматизированные сборки с помощью Visual Studio? - PullRequest
9 голосов
/ 22 августа 2009

Я работаю в небольшом .net магазине, где в настоящее время мы создаем все наши решения с использованием Visual Studio IDE. Мы хотим перейти к точке, в которой мы полностью контролируем наши сценарии MSBuild для сборки, тестирования, развертывания, используя задачи сообщества MSBuild и т. Д.

Наверное, мой вопрос: что будет отличаться в опыте разработки Visual Studio?

Если мы создаем наши собственные файлы MSBuild .proj, значит ли это, что у нас больше нет файлов .csproj? Как сейчас выглядят проекты в VS?

Я что-то упускаю действительно очевидное?

UPDATE Спасибо всем, что нашли время ответить. Мне известны некоторые инструменты сборки: CruiseControl, TeamCity и т. Д., А также то, что проекты (.csproj и т. Д.) - это просто файлы MSBuild. Я пытаюсь разобраться с теми людьми, которые решили написать свои собственные сценарии и свои собственные файлы .proj. Используют ли они файлы VS.csproj просто как «контейнер» для хранения своих файлов кода в IDE? Как они запускают свои собственные сборки для разработчиков? Они просто запускают MSBuild из командной строки? У вас есть кнопка на панели инструментов, которая делает то же самое?

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

Ответы [ 6 ]

6 голосов
/ 22 августа 2009

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

Также просто для пояснения, мы также используем автоматизированный сервер сборки (Hudson with .Net plugins), которыйиспользует msbuild для автоматизации процесса.

2 голосов
/ 22 августа 2009

Существует несколько хороших инструментов для автоматической и непрерывной сборки, основанных на MSBuild. Ваши файлы проекта C # уже ARE файлы MSBuild - так что в действительности, начиная с VS2005, вы использовали MSBuild на своей локальной рабочей станции для создания своей сборки - вы просто не могли знать об этом: -)

Помимо CruiseControl.NET (упомянутого JP), который определенно стоит посмотреть, я бы также порекомендовал еще два продукта:

  • FinalBuilder Server , который кажется почти неизвестным подавляющему большинству разработчиков (но он определенно заслуживает большего внимания! Отличный инструмент). У них также есть автономная настольная версия FinalBuilder, если вам это может понадобиться. Это не бесплатно - но в 100 долларов за одного пользователя (и 450 долларов за 5), это действительно не огромные расходы

  • TeamCity от JetBrains - также известного своим продуктом Resharper в мире .NET - который предлагает бесплатную Pro-версию для команд до 20 пользователей / планов сборки и гораздо более дорогой Корпоративная версия, если вы выросли :-)

По сравнению с CruiseControl.NET, оба предлагают приятный, дружественный графический интерфейс для настройки как ваших сборок, так и мониторинга их.

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

Вы действительно не ошибетесь с непрерывной интеграцией! Я не мог быть без немедленной обратной связи по сборке ......

Марк

2 голосов
/ 22 августа 2009

что будет отличаться в опыте разработки Visual Studio?

Обычно ничего. На самом деле, если вы все делаете правильно, это должно быть прозрачно; вашей IDE не должно быть важно, какой менеджер сборки вы используете. Вот почему такие решения, как CruiseControl.NET и Hudson, хороши.

Если мы создаем наши собственные файлы MSBuild .proj, значит ли это, что у нас больше нет файлов .csproj? Как сейчас выглядят проекты в VS?

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

2 голосов
/ 22 августа 2009

Вам следует взглянуть на CruiseControl.NET , а не на собственный автоматизированный процесс сборки и CI. Это делает процесс намного проще, и он может выполнять дополнительные действия, такие как запуск до тестирования, инструменты покрытия кода или что-то еще, как часть процесса сборки.

1 голос
/ 24 августа 2009

Спасибо всем за ваши ответы, но после небольшого исследования я нашел несколько идей о том, как сделать это немного по-другому:

  • для расширения процесса сборки за пределы файлов .sln & .csproj
  • пока еще используется Visual Studio
  • и держись в мире MSBuild как можно больше
  • добавление возможностей серверов сборки, таких как TeamCity и Hudson, где требуется
  • но не зависит от этих серверов для функциональности, которую должен обеспечить скрипт сборки.

Итак, что я нашел: Это старое сообщение в блоге Скотта Хансельмана о код организации . Здесь он использует Nant вместо MSBuild, но основная идея заключается в том, чтобы выполнить любой проект nant / msbuild, который вы хотите, через пакетный файл .bat.

"В этом каталоге souce есть такие вещи, как build.bat и buildpatch.bat. Цель состоит в том, чтобы люди могли получить материал из системы контроля версий и набрать BUILD и быть где-нибудь полезным. ОЧЕНЬ утешительно иметь возможность надежно и просто собрать всю систему. "

Из этого я могу видеть, что он (очевидно) все еще использует .sln и .csproj для хранения своих файлов вместе для VS - и может собирать через VS при необходимости - но на самом деле делает свою сборку через файлы .build Nant, выполняемые через .bat.

Этот другой пост (также от Скотта Хансельмана) показывает, как вы можете запускать внешние инструменты (такие как MSBuild или .bat файл) из Visual Studio. Итак, я создал файл build.bat, который выглядит так:

@echo off
echo Building %1 solution from build.bat
echo Directory: %~p1
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe %~f1 %2

(я получил фанки модификаторов параметров ~ p и ~ f от здесь ;% ~ f1 расширяет MySolution.sln до полного пути sln); -)

Затем я настроил диалоговое окно «Внешние инструменты» в Visual Studio так, чтобы: - команда "build.bat" Аргументы: "$ (SolutionFileName) / v: m" - начальный каталог "& (SolutionDir)"

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

Во всяком случае, это всего лишь некоторые идеи (по общему признанию, из чьего-то мозга!), Но это дает мне больше понимания сборок и того, как их можно реализовать. Существуют некоторые ограничения (например, ошибки не отображаются в окне списка ошибок), но я уверен, что при необходимости это можно будет преодолеть.

Я собираюсь попробовать и посмотреть, чего я могу достичь только на MSBuild, а затем также попробовать подключиться к Хадсону и посмотреть, что готовит! : -)

Кстати, если кто-то все еще читает на этом этапе и имеет мнение о том, является ли материал, который я представил в моем собственном ответе, хорошим / плохим / правильным / неправильным / излишним / устаревшим / ошибочным / каким бы то ни было, пожалуйста, почувствуйте свободно выражать свое мнение.

Хороший, Пит.

1 голос
/ 23 августа 2009

Мы используем TeamCity на работе; мы начали с CruiseControl.NET, но переключились, когда другой разработчик указал мне, что иначе я буду поддерживать сборку cc. ;) Если серьезно, TeamCity очень прост в освоении и использовании.

Я задавал похожие вопросы, когда впервые услышал о непрерывной интеграции. Нужно ли переписывать (и поддерживать) все решения и проекты вручную? Вам нужно изучить команды MSBuild? Краткий ответ №

Как отметил г-н Харви, вы можете просто вызвать MSBuild для созданного VS решения или файла проекта, и он создаст его для вас. TeamCity будет обрабатывать это автоматически.

Если вы хотите большей гибкости, я бы порекомендовал NAnt . Я работал со скриптами MSBuild для ручного кодирования, и это упражнение разочаровало. NAnt имеет более чистый синтаксис и (для меня) легче в использовании и чтении. Мы используем NAnt для причудливых вещей и (снова) вызываем MSBuild из NAnt, когда хотим построить проект или решение. TeamCity поддерживает NAnt.

Подводя итог, для нас ничего действительно не изменилось в Visual Studio. Мы по-прежнему создаем и поддерживаем наши проекты и решения таким же образом. Когда мы проверяем их в системе управления версиями (TFS), TeamCity автоматически подхватывает их, строит решения и запускает наши (NUnit) тесты. У нас также есть настроенные сборки развертывания в один клик (в TeamCity с использованием NAnt).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...