Различия между Visual Studio (.sln) построить бегун и MSBuild

Question

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

1. Visual Studio (SLn)
2. MSBuild
3. Visual Studio 2003

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

Принимая этот вопрос, у нас есть эта сборка бегунков для EXE-файлов:

1. .NET Process Runner
2. командной строки

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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