Различия между Visual Studio (.sln) build runner и MSBuild

Я пытаюсь установить TeamCity для выполнения CI с использованием .Net и настройки бегунов сборки. У меня есть:

  • Visual Studio (sln)
  • MSBuild
  • Visual Studio 2003

Какая разница? Почему три проекта работают над одним и тем же проектом? (За исключением 2003 года, который только для 2003 года я верю, почему?)

Взяв эту проблему, у нас есть это бегущие сборки для файлов .exe:

  • .NET Process Runner
  • Командная строка

Линейка сборки командной строки не работает с какой-либо сборкой .net? Почему .Net Process Runner?

ОТВЕТЫ

Ответ 1

Visual Studio (sln)
Если ваше решение малое, и вам не нужно делать какие-либо причудливые вещи, вы можете использовать бегун сборки Visual Studio (sln). Он делает то же самое, что и при создании Project- > Build (из меню VS). Этот параметр очень прост в настройке, несколько кликов и ваш сервер CI компилируют ваше решение.

MSBuild
Если вам нужно выполнить более сложные сценарии, помимо простой компиляции, например, применить различные файлы конфигурации, вставить преобразованные значения в файл конфигурации, развернуть двоичные файлы и т.д., Вы должны выбрать вариант MSBuild. Вы узнаете, когда вам нужно это использовать, просто потому, что sln-строитель не сможет делать что-то. Этот параметр требует некоторых знаний языка сценариев сборки, который основан на задачах и xml-подобных.

Ответ 2

Когда вы используете MSBuild для создания .SLN файла (не являющегося документом MSBuild), он создает файл MSBuild в памяти, который ссылается на все проекты для сборки в указанной конфигурации, а затем выполняет его. Когда вы используете Visual Studio для сборки, вы вызываете DevEnv.com вместо этого.

Существуют определенные типы проектов (С++ в 2005/2008 и VDPROJ в 2005/2008/2010), которые не являются файлами MSBuild и не могут быть созданы с использованием только MSBuild. Вы получите предупреждение о сборке, в котором говорится, что один или несколько проектов недействительны для проектов MSBuild и не могут быть построены.

В общем я стараюсь поддерживать скудные и средние машины сборки и при необходимости устанавливать Visual Studio.

Ответ 3

Я заметил очень мало между ними. В частности, в нашем примере нам нужно было построить .vdproj. Теперь после поиска в Интернете, где есть два бегуна, это бегун из командной строки или Visual Studio (sln). Однако при выполнении типа бегущей среды Visual Studio (sln) мы получили следующую ошибку: "[Предупреждение] C:\BuildAgent\work\1bd75058d7bca32b\POS\PoSWidgetInstaller\myInstaller.vdproj.metaproj предупреждение MSB4078: файл проекта" myInstaller\myInstaller.vdproj "не поддерживается MSBuild и не может быть создан."

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

Ответ 4

Если вы используете файлы решений (Visual Studio), которые означают, что вам необходимо лицензировать копию Visual Studio для вашего сервера сборки вместе с установкой/обслуживанием, которая сопровождается этим. Если вы используете MSBuild, вам это не нужно, все, что вам нужно, это установки .net framework. Единственное реальное различие между ними состоит в том, что Visual Studio имеет всевозможные переменные среды, установленные и использующие такие вещи, как порядок сборки. Хотя MSBuild не имеет каких-либо переменных среды, установленных по умолчанию, и не распознает порядок сборки, он только реконструирует параметры. Это будет немного легче, хотя в Visual Studio, и вы не столкнетесь с теми случаями, когда вы были в зависимости от визуальной студии, чтобы скрыть некоторую неряшливость.