Почему я должен использовать MSBuild вместо файлов Visual Studio Solution?

Мы используем TeamCity для непрерывной интеграции и собираем наши релизы с помощью файла решения (.sln). В прошлом я использовал Makefiles для различных систем, но никогда не использовал msbuild (я слышал, что это похоже на Makefiles + XML mashup). Я видел много сообщений о том, как использовать msbuild напрямую вместо файлов решения, но я не вижу четкого ответа на вопрос, зачем это делать.

Итак, зачем нам переходить с файлов решений на «make-файл» MSBuild? У нас есть пара выпусков, которые отличаются #define (специализированными сборками), но по большей части все работает.

Больше всего беспокоит то, что теперь нам нужно поддерживать две системы при добавлении проектов / исходного кода.

ОБНОВИТЬ:

Могут ли люди пролить свет на жизненный цикл и взаимодействие следующих трех компонентов?

1. Visual Studio .sln файл
2. Множество файлов уровня .csproj проекта (которые я понимаю как «sub» сценарии msbuild)
3. Пользовательский скрипт msbuild

Можно ли с уверенностью сказать, что файлы .sln и .csproj используются / поддерживаются в обычном режиме из графического интерфейса IDE Visual Studio, а пользовательский сценарий msbuild написан от руки и обычно использует уже существующие отдельные файлы .csproj «как есть»? Это один из способов уменьшить дублирование при обслуживании ...

Был бы признателен за это на опыте других людей

Первый факт заключается в том, что файл решения почти волшебным образом становится файлом MSBuild, когда MSBuild выполняет его, что и происходит при создании решения в visual studio. Кроме того, все эти файлы проекта - это просто файлы msbuild, управляемые Visual Studio. Фактически, файлы проекта обрабатывают большую часть настоящей грязной работы, независимо от того, строите ли вы из решений или строите из собственного скрипта msbuild.

Мы также используем TeamCity для создания и публикации приложений, и для большинства проектов мы обычно получим собственные сценарии msbuild. Роль, которую играют эти сценарии - что на самом деле непросто с файлом решения - упаковывает проект для развертывания или распространения. Обычно эти сценарии обрабатывают некоторые более оперативные аспекты, такие как создание веб-проекта в определенной папке или копирование в работающих конфигурациях, а не в конфигурациях разработки. Тяжелая работа, как правило, обрабатывается в самих файлах проекта - скрипт сборки просто ссылается на них, мы не пытаемся воссоздать это колесо. В целом, он прекрасно работает, и на самом деле не так много дублированного кода.

Makefile для msbuild - это файл .sln (или файл vcproj).

Типичная командная строка msbuild будет выглядеть примерно так:

msbuild /p:Configuration=Release BigProject.sln

Смысл использования msbuild в том, что вы можете создавать сценарии и автоматизировать процесс сборки. Независимо от того, знали вы об этом или нет, TeamCity все время использует msbuild.

Позвольте мне предложить мой взгляд на этот вопрос.

Хотя вы, конечно, можете просто использовать свой файл .SLN в качестве «процесса сборки», сам файл действительно не представляет собой процесс сборки. Файл решения действительно является частью Visual Studio и используется для разработки. Но Visual Studio - это только часть процесса сборки и выпуска. Вы не можете полагаться на решения для управления сборкой, и решения, безусловно, не предлагают масштабируемой ситуации сборки.

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

Создание процесса сборки требует инвестиций, но в некоторых случаях они необходимы. Вот некоторые факторы, которые способствуют процессу msbuild:

• Ваш продукт имеет несколько команд (кросс-функциональных или других), которые работают в одном командном проекте
• В вашей организации есть только один командный проект (так должно быть в 99% традиционных магазинов, даже в тех, где более 200 разработчиков)
• У вас есть более 20 проектов, которые необходимо построить, некоторые из которых зависят от других и поддерживаются различными командами.
• Ваш продукт включает в себя несколько технологий .NET (C #, C ++, VB, F #, ASP.NET и т. Д.) Или даже не-.NET-технологии (Grunt, node, npm, Java и т. Д.)
• Ваш продукт имеет тяжелые зависимости или построен на основе тяжелой платформы. SharePoint, в качестве примера

Позвольте мне привести пример, чтобы расширить мой последний пункт. Моя текущая компания занимается разработкой SharePoint. Как минимум, для разработки SharePoint требуется установить фундамент SharePoint для выполнения сборок на проектах SharePoint. Говоря об упрощенном сервере сборки, совершенно непрактично требовать, чтобы на сервере сборки был установлен SharePoint. SharePoint не только зверь с высокими требованиями, но и может иметь серьезные последствия для производительности при сборке, а сборки должны быть максимально быстрыми и экономичными. Использование MSBuild позволяет мне устранить это требование установки на сервере сборки. На самом деле, наш сервер сборки не имеет никаких требований к установке, кроме .NET Framework (требуется MSBuild) и Node.

В качестве ссылки я бы порекомендовал проверить эту книгу Саида Ибрагима Хашими: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 & ключевые слова = MSBuild + надежный + сборка

Это именно тот вопрос, который я задавал себе несколько месяцев назад! У нас все было хорошо настроено:

• Файл решения красиво в корне репозиториев
• Этапы сборки, настроенные в Teamcity, например
  • Восстановить пакеты NuGet
  • Построить решение
  • Выполнить юнит-тесты
  • Настройка среды тестирования интеграции
  • Запустите интеграционные тесты
  • Разрушить среду тестирования интеграции
  • Создать пакет развертывания
  • Построить скрипт миграции

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

Когда у вас есть скрипт сборки, он знает все, что нужно сделать, и имеет все переменные на месте. Когда вы используете CI-сервер в качестве сценария сборки, и возникает какая-то проблема, например, сложный тест, не выполняющийся или не требующий сборки пакета развертывания вручную (согласно моему примеру), вам необходимо вручную собрать все этапы сборки.

Итак, вкратце , почему (MS) скрипт сборки? Потому что у вас будет больше требований, когда речь заходит о вашей сборке. Возможно, вы захотите запустить несколько тестов и сгенерировать из этого артефакты. Вы, вероятно, хотите сделать развертывания. И когда все, что вам нужно, должно быть работоспособным, будь то на сервере сборки или на вашей машине, оно может оказаться где угодно, только не в сценарии сборки.