Что такое целевая сборка в visual studio
Для эффективной разработки и выполнения сборочного процесса в групповой среде, важно начать с создания правильной структуры проекта, одинаковой на всех компьютерах разработчиков и на сервере сборки (build server).
В этой главе даны рекомендации по:
К наиболее распространенным типам локальных проектов относятся Windows-приложения и библиотеки классов, хотя существует и множество других типов, в том числе проекты служб, консольных приложений, баз данных и т. д.
Файлы решений (с расширением .sln) объединяют в группу связанные проекты и применяются в основном для управления процессом сборки. С их помощью можно управлять зависимостями и порядком, в котором собираются содержащиеся в них проекты.
Внимание Проект может быть частью одного или нескольких решений, но решения не могут включать другие решения.
Рис. 3.1 иллюстрирует связь между проектами и решениями и типы файлов, в которых VSS хранит параметры уровней решения и проекта.
Solution - Решение
Dependencies - Зависимости
Project - Проект
User Specific File (Not Version Controlled) - Файл, специфичный для пользователя (вне системы контроля версий)
AppName - Имя приложения
Non-User Specific File (Version Controlled) - Файл, не специфичный для пользователя (в системе контроля версий)
Решения и сборочные зависимости
Файлы, включаемые в систему контроля исходного кода
Прочие файлы, в том числе пользовательский файл решения (.suo) и файл проекта (.csproj или .vbproj), тоже обновляются.
Разбиение решений и проектов на отдельные части
Способ разбиения решений и проектов существенно влияет на процессы разработки и сборки в среде групповой разработки.
Существует три основных модели разбиения решений и проектов. Их список дан в порядке предпочтительности:
- Единое решение.
- Единое решение, разбитое на части.
- Несколько решений.
Внимание Если у вас нет веских причин на то, чтобы задействовать модель на основе нескольких решений, избегайте ее и принимайте либо модель на основе единственного решения, либо (для больших систем) модель на основе решения, разбитого на части. С ними проще работать; к тому же, у них есть ряд важных преимуществ по сравнению с моделью на основе нескольких решений, о чем и рассказывается в следующих разделах.
По возможности применяйте модель на основе единственного решения
File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution 1 - Решение 1
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки, в том числе компоненты сторонних поставщиков
Рис. 3.2. Модель на основе единственного решения
По возможности используйте именно эту модель, так как у нее есть ряд существенных преимуществ.
Преимущества
Недостатки
- масштабирование этой модели ограничено. Даже если вам понадобится всего один проект из решения, придется получать исходный код всех проектов этого решения;
- даже незначительные изменения в единственном файле исходного кода в одном проекте могут вызвать повторную сборку (rebuild) многих проектов в решении из-за зависимостей между проектами. Если в проекте, на который вы ссылаетесь, изменяется интерфейс сборки (assembly), вам потребуется перекомпилировать клиентский проект. А компиляция зависимых проектов может быть весьма длительной, особенно если в решении их много.
Для больших систем используйте модель, в которой решение разбивается на части
В больших системах, где нужно уменьшить число проектов и файлов исходного кода, требуемых на каждом компьютере разработчика, подумайте о выделении связанных наборов проектов в файлы подпроектов.
Это позволит вам и вашим коллегам работать над раздельными подсистемами меньшего размера в пределах внутренней системы.
Примечание Включить один проект в несколько файлов решения можно, а добавить решение в другие решения нельзя.
На рис. 3.3 показана модель решения, разбитого на части. Обратите внимание на использование отдельных файлов решения, позволяющих работать с подсистемами меньшего размера в границах внутренней системы. Также заметьте, что в результате проекты содержатся более чем в одном файле решения. Например, проекты D и H размещаются в трех файлах решения, включая главный файл решения.
File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution 1 - Решение 1
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки и компоненты оот сторонних поставщиков
Master Solution - Главное решение
Рис. 3.3. Модель решения, разбитого на части
- все проекты содержатся в главном файле решения. Он используется сборочным процессом для сборки всей системы. Если вы работаете с файлом проекта верхнего уровня, вы работаете и с главным решением;
- между индивидуальными проектами существуют ссылки на проекты;
- для некоторых файлов проектов вводятся отдельные файлы решения. При желании можно создать файл решения для каждого проекта в системе. Каждый файл решения содержит файл основного проекта и все нижестоящие проекты, от которых он зависит, а также проекты, от которых зависят только что упомянутые нижестоящие проекты, - и так до конца по всей цепочке зависимостей;
- отдельные файлы решения позволяют работать с подсистемами меньшего размера, по-прежнему используя основные преимущества ссылок на проекты. В каждом файле подрешения между составляющими его проектами создаются ссылки на проекты.
Примечание Не разделяйте два ссылающихся друг на друга проекта между решениями, так как в этом случае вам потребуется файловая ссылка, чего по возможности следует избегать. Подробнее на эту тему см. раздел Ссылки на сборки в главе 4 "Управление зависимостями".
Преимущества
Недостатки
Используйте модель на основе нескольких решений, только если это действительно необходимо
- нет главного файла решения;
- между проектами в разных решениях используются файловые ссылки (хотя ссылки на проекты по-прежнему применяются в рамках проектов одного решения);
- сценарий сборки системы, выполняемый на сервере сборки, последовательно компилирует каждое решение на основе известных отношений зависимости (dependency relationships). Сценарий сборки помещает результаты в фиксированное место на сервере.
Модель на основе несокльких решений показана на рис. 3.4.
File Reference - Файловая ссылка
Project Reference - Ссылка на проект
Solution - Решение
Project - Проект
Outer System Boundary - Внешняя граница системы
Inner System Boundary - Внутренняя граница системы
External Assemblies Third Party Components - Внешние сборки и компоненты от сторонних поставщиков
Рис. 3.4. Модель на основе нескольких решений
Преимущества
- Каждый проект содержится только в одном решении. Поэтому добавлять и удалять проекты из системы проще.
- Можно разделить систему на несколько решений, исходя из логических границ и не обращая внимания на зависимости между проектами. Так, разделение может быть основано на областях бизнес-функциональности.
Недостатки
Рекомендации по группировванию проектов в решения
Используйте согласованную структуру папок для проектов и решений
Определите общую корневую папку
Определите общую корневую папку, например C:\Projects в файловой системе и $/Projects в VSS. Она будет служить контейнером для всех разрабатываемых систем.
В общей корневой папке создайте корневые папки для всех систем, например C:\Projects\MyCompanysInsuranceApp и $/Projects/MyCompanysInsuranceApp соответственно.
Применяйте иерархическую структуру папок для решений и проектов
Примечание Если вы используете модель решения, разбитого на части, поместите папки проектов в папку с главным файлом решения. Во все подрешения включайте файлы проектов оттуда напрямую.
Рекомендуемая структура показана на рис. 3.5.
Включайте в имя решения слово Solution или Soln - так проще различать имена решения и проекта.
Рекомендуемая структура приведена на рис. 3.6. Заметьте, что папка проекта и виртуальный корень Microsoft Internet Information Server (IIS) совпадают.
Local File System - Локальная файловая система
VSS Project Structure - Структура проекта VSS
Project folder AND IIS Virtual Root - Папка проекта и виртуальный корень IIS
Рис. 3.6. Рекомендуемая структура Web-приложения
Чтобы создать новое Web-приложение с такой структурой
Как разбить Web-приложение на несколько проектов
Внимание Подход, при котором используется один проект, проще, так что разбивайте Web-приложение на несколько проектов, только если это действительно необходимо. Обычно такая необходимость возникает в очень больших Web-приложениях.
Дополнительные сведения
Как создать новый проект, отличный от Web-приложения
Далее рассказывается, как создать проект, отличный от Web-приложения, скажем, консольную или Windows-программу, библиотеку классов или сервис. Предполагается, что решение называется MyWinAppSolution, а проект - MyWinApp. Рекомендуемая структура приведена на рис. 3.7.
Local File System - Локальная файловая система
VSS Project Structure - Структура проекта VSS
Рис. 3.7. Рекомендуемая структура проекта для приложений, не связанных с Web
Чтобы создать новое приложение, отличное от Web, с такой структурой
О добавлении нового проекта и решения к Visual SourceSafe см. раздел Как зарегистрировать в VSS новое решение главы 6 "Работа с Visual SourceSafe".
Тщательно обдумайте соглашения об именовании
Тщательно и заранее обдумайте, как вы будете именовать проекты, сборки, папки и пространства имен. Хотя эти элементы можно переименовать на более поздних этапах цикла разработки, старайтесь этого избегать. О том, как переименовать проект, см. раздел Переименование проекта главы 6 "Работа с Visual SourceSafe".
Также стремитесь к непротиворечивости имен, поскольку это существенно упрощает организацию проекта.
Используйте общие имена для проектов и сборок
Имя выходной сборки должно всегда совпадать с именем проекта, в котором она создается. Например, сборка MyCompany.Utilities.Data.dll должна создаваться в проекте MyCompany.Utilities.Data.
При изменении имени выходной сборки измените имя проекта и наоборот.
Используйте общее имя корневого пространства имен
Корневое пространство имен, в котором вы размещаете ваши типы (структуры, классы, интерфейсы и т. д.), должно соответствовать имени проекта и сборки.
Так, в сборке MyCompany.Utilities.Data.dll корневое пространство имен должно называться MyCompany.Utilities.Data.
Используйте общие имена для папок VSS и локальных папок
Как уже говорилось, синхронизируйте имена папок решений и проектов с эквивалентными именами папок в VSS.
Целевые объекты необходимо упорядочить, если входные данные для одного целевого объекта зависят от выходных данных другого целевого объекта. Эти атрибуты можно использовать для задания порядка выполнения целевых объектов:
InitialTargets . Этот атрибут Project указывает целевые объекты, которые будут выполняться первыми, даже если целевые объекты указаны в командной строке или в атрибуте DefaultTargets .
DefaultTargets . Этот атрибут Project указывает целевые объекты, которые будут выполняться, если целевой объект не указан явно в командной строке.
DependsOnTargets . Этот атрибут Target указывает целевые объекты, которые необходимо выполнить перед запуском этого целевого объекта.
BeforeTargets и AfterTargets . Эти атрибуты Target указывают, что этот целевой объект должен выполняться до или после указанных целевых объектов (MSBuild 4.0).
Целевой объект никогда не выполняется дважды во время сборки, даже если от него зависит последующий целевой объект в сборке. После запуска целевого объекта его участие в сборке завершается.
Целевые объекты могут иметь атрибут Condition . Если указанное условие имеет значение false , целевой объект не выполняется и не влияет на сборку. Дополнительные сведения об условиях см. в разделе Условия.
Начальные целевые объекты
Атрибут InitialTargets элемента Project указывает целевые объекты, которые будут выполняться первыми, даже если целевые объекты указаны в командной строке или в атрибуте DefaultTargets . Начальные целевые объекты обычно используются для проверки ошибок.
Значение атрибута InitialTargets может представлять собой разделенный точкой с запятой упорядоченный список целевых объектов. В следующем примере указывается, что выполняется целевой объект Warm , а затем целевой объект Eject .
Импортированные проекты могут иметь собственные атрибуты InitialTargets . Все начальные целевые объекты собираются вместе и выполняются по порядку.
Целевые объекты по умолчанию
Атрибут DefaultTargets элемента Project указывает, какой целевой объект или целевые объекты создаются, если целевой объект не задан явным образом в командной строке.
Значение атрибута DefaultTargets может представлять собой разделенный точкой с запятой упорядоченный список целевых объектов по умолчанию. В следующем примере указывается, что выполняется целевой объект Clean , а затем целевой объект Build .
Целевые объекты по умолчанию можно переопределить с помощью параметра командной строки -target. В следующем примере указывается, что выполняется целевой объект Build , а затем целевой объект Report . При указании целевых объектов таким образом все целевые объекты по умолчанию игнорируются.
Если указаны начальные целевые объекты и целевые объекты по умолчанию, и не указаны целевые объекты командной строки, MSBuild сначала выполняет начальные целевые объекты, а затем целевые объекты по умолчанию.
Импортированные проекты могут иметь собственные атрибуты DefaultTargets . Первый атрибут DefaultTargets определяет, какие целевые объекты по умолчанию будут выполняться.
Первый целевой объект
Если начальные целевые объекты, целевые объекты по умолчанию или целевые объекты командной строки отсутствуют, MSBuild сначала выполняет первый обнаруженный целевой объект в файле проекта или любом импортированном файле проекта.
Зависимости целевого объекта
Целевые объекты могут описывать отношения зависимости друг от друга. Атрибут DependsOnTargets указывает, что целевой объект зависит от других целевых объектов. Например, примененная к объекту директива
сообщает MSBuild, что целевой объект Serve зависит от целевых объектов Chop и Cook . MSBuild выполняет целевой объект Chop , а затем выполняет объект Cook перед выполнением Serve .
Целевые объекты, выполняемые до и после заданного целевого объекта
В MSBuild 4.0 можно указать порядок целевых объектов с помощью атрибутов BeforeTargets и AfterTargets .
Рассмотрим следующий сценарий.
Чтобы создать промежуточный целевой объект Optimize , который будет выполняться после объекта Compile , но до объекта Link , добавьте следующий целевой объект в любое место элемента Project .
Определение порядка сборки целевых объектов
MSBuild определяет порядок сборки целевых объектов следующим образом.
Выполняются целевые объекты InitialTargets .
Выполняются целевые объекты, заданные в командной строке параметром -target. Если целевые объекты не указаны в командной строке, выполняются целевые объекты DefaultTargets . Если оба типа отсутствуют, выполняется первый обнаруженный целевой объект.
Выполняется оценка атрибута Condition целевого объекта. Если атрибут Condition присутствует и имеет значение false , целевой объект не выполняется и не влияет на сборку.
Другие целевые объекты, в которых указываются условные целевые объекты в BeforeTargets или AfterTargets , по-прежнему выполняются в предписанном порядке.
Прежде чем целевой объект выполняется или пропускается, выполняются его целевые объекты DependsOnTargets , если атрибут Condition не применяется к целевому объекту и не дает в результате false .
Целевой объект считается пропущенным, если он не выполняется, так как его выходные элементы актуальны (см. раздел Инкрементная сборка). Эта проверка выполняется непосредственно перед выполнением задач в целевом объекте и не влияет на порядок выполнения целевых объектов.
Перед выполнением или пропуском целевого объекта выполняются все прочие целевые объекты, у которых он указан в атрибуте BeforeTargets .
Перед выполнением целевого объекта сравниваются его атрибуты Inputs и Outputs . Если MSBuild определяет, что какие-либо выходные файлы неактуальны по отношению к соответствующему входному файлу или файлам, то MSBuild выполняет целевой объект. В противном случае MSBuild пропускает целевой объект.
После выполнения или пропуска целевого объекта выполняются все прочие целевые объекты, у которых он указан в атрибуте AfterTargets .
В этом пошаговом руководстве показано, как создать проект Visual Studio C++ из командной строки с помощью MSBuild. Вы узнаете, как создать файл проекта на основе XML .vcxproj для консольного приложения Visual C++. После сборки проекта вы узнаете, как настроить процесс сборки.
Не используйте этот подход, если позднее вы намереваетесь изменять файл проекта с помощью интегрированной среды разработки Visual Studio. Если вы создадите файл .vcxproj вручную, есть вероятность того, что среде Visual Studio не удастся загрузить или изменить его, особенно если в элементах проекта используются подстановочные знаки. Дополнительные сведения см. в разделах Структура файлов .vcxproj и .props , а также Файлы .vcxproj и подстановочные знаки.
В данном пошаговом руководстве рассмотрены следующие задачи:
Создание исходных файлов C++ для проекта
Создание XML-файла проекта MSBuild
Сборка проекта с помощью MSBuild
Настройка проекта с помощью MSBuild
Предварительные требования
Для выполнения данного пошагового руководства вам потребуется следующее.
Копия Visual Studio с установленной рабочей нагрузкой Разработка классических приложений на C++ .
Общее представление о системе MSBuild.
Создание исходных файлов C++
В этом пошаговом руководстве будет создан проект, включающий в себя исходный файл и файл заголовка. Исходный файл main.cpp содержит функцию main для консольного приложения. Файл заголовка main.h содержит код для включения файла заголовка <iostream> . Эти файлы C++ можно создать в Visual Studio или текстовом редакторе, таком как Visual Studio Code.
Создание исходных файлов C++ для проекта
Создайте каталог для своего проекта.
Создайте файл с именем main.cpp и добавьте в него следующий код.
Создайте файл с именем main.h и добавьте в него следующий код.
Создание XML-файла проекта MSBuild
Файл проекта MSBuild — это XML-файл, содержащий корневой элемент проекта ( <Project> ). В примере проекта, который вам предстоит создать, элемент <Project> содержит семь дочерних элементов.
Три тега групп элементов ( <ItemGroup> ) определяют конфигурацию и платформу проекта, имя исходного файла и имя файла заголовка.
Три тега импорта ( <Import> ) определяют расположение параметров Microsoft Visual C++.
Тег группы свойств ( <PropertyGroup> ) определяет параметры проекта.
Создание файла проекта MSBuild
В текстовом редакторе создайте файл проекта с именем myproject.vcxproj , а затем добавьте приведенный ниже корневой элемент <Project> . (Используйте ToolsVersion="14.0" для Visual Studio 2015, ToolsVersion="15.0" для Visual Studio 2017 или ToolsVersion="16.0" для Visual Studio 2019.)
В следующих шагах процедуры между корневыми тегами <Project> будут вставлены элементы.
В элемент <ItemGroup> добавьте приведенные ниже два дочерних элемента <ProjectConfiguration> . Они определяют конфигурации отладки и выпуска для 32-разрядной операционной системы Windows:
Добавьте элемент <Import> , определяющий путь к параметрам C++ по умолчанию для проекта.
Добавьте элемент группы свойств ( <PropertyGroup> ), определяющий свойства проекта <ConfigurationType> и <PlatformToolset> . (Используйте значение v140 для <PlatformToolset> для Visual Studio 2015, v141 для Visual Studio 2017 или v142 для Visual Studio 2019.)
Добавьте элемент <Import> , определяющий путь к текущим параметрам C++ для проекта.
Добавьте в элемент <ItemGroup> дочерний элемент <ClCompile> . Он указывает имя исходного файла C/C++, подлежащего компиляции:
<ClCompile> — это цель сборки, которая определяется в целевом каталоге по умолчанию.
Добавьте в элемент <ItemGroup> дочерний элемент <ClInclude> . Он указывает имя файла заголовка для исходного файла C/C++:
Добавьте элемент <Import> , определяющий путь к файлу, в котором определен целевой объект проекта.
Полный файл проекта
Ниже приведен полный код файла проекта, созданного в предыдущей процедуре. (Используйте ToolsVersion="15.0" для Visual Studio 2017 или ToolsVersion="14.0" для Visual Studio 2015.)
Сборка проекта с помощью MSBuild
Чтобы выполнить сборку консольного приложения, в командной строке введите следующую команду.
msbuild myproject.vcxproj /p:configuration=debug
MSBuild создаст каталог для выходных файлов, а затем скомпилирует и скомпонует проект для создания программы Myproject.exe . По завершении процесса сборки используйте следующую команду для запуска приложения из папки отладки.
Настройка проекта
MSBuild позволяет выполнять предварительно определенные целевые объекты сборки, применять пользовательские свойства и использовать настраиваемые средства, события и этапы сборки. В этом разделе рассмотрены следующие задачи.
Использование MSBuild с целевыми объектами сборки
Использование MSBuild со свойствами сборки
Использование MSBuild с 64-разрядным компилятором и средствами
Использование MSBuild с разными наборами средств
Добавление настроек MSBuild
Использование MSBuild с целевыми объектами сборки
Целевой объект сборки — это именованный набор предварительно определенных или пользовательских команд, которые могут выполняться во время сборки. Для указания целевого объекта сборки используйте параметр командной строки target ( /t ). В примере проекта myproject предварительно определенный целевой объект clean удаляет все файлы в папке отладки и создает новый файл журнала.
В командной строке введите следующую команду для очистки myproject .
Использование MSBuild со свойствами сборки
Параметр командной строки property ( /p ) позволяет переопределить свойство в файле сборки проекта. В примере проекта myproject конфигурация сборки выпуска или отладки указывается в свойстве Configuration . Операционная система, в которой будет выполняться собранное приложение, указывается в свойстве Platform .
В командной строке введите приведенную ниже команду, чтобы создать сборку отладки приложения myproject , предназначенную для выполнения в 32-разрядной версии Windows.
msbuild myproject.vcxproj /p:configuration=debug /p:platform=win32
Допустим, что в примере проекта myproject также определена конфигурация для 64-разрядной версии Windows и еще одна конфигурация для пользовательской операционной системы myplatform .
В командной строке введите приведенную ниже команду, чтобы создать сборку выпуска, предназначенную для выполнения в 64-разрядной версии Windows.
msbuild myproject.vcxproj /p:configuration=release /p:platform=x64
В командной строке введите приведенную ниже команду, чтобы создать сборку выпуска, предназначенную для выполнения на платформе myplatform .
msbuild myproject.vcxproj /p:configuration=release /p:platform=myplatform
Использование MSBuild с 64-разрядным компилятором и средствами
Если вы установили Visual Studio в 64-разрядной версии Windows, по умолчанию были также установлены 64-разрядные собственные и кроссплатформенные средства. Чтобы настроить сборку приложения с использованием 64-разрядного компилятора и средств в MSBuild, задайте свойство PreferredToolArchitecture . Оно не влияет на конфигурацию проекта или свойства платформы. По умолчанию используется 32-разрядная версия средств. Чтобы использовать 64-разрядную версию компилятора и средств, добавьте следующий элемент группы свойств в файл проекта Myproject.vcxproj после элемента <Import /> файла Microsoft.Cpp.default.props .
Чтобы выполнить сборку приложения с помощью 64-разрядных средств, в командной строке введите приведенную ниже команду.
msbuild myproject.vcxproj /p:PreferredToolArchitecture=x64
Использование MSBuild с другим набором средств
Если у вас установлены наборы средств и библиотеки для других версий Visual C++, MSBuild может выполнять сборку приложений как для текущей версии Visual C++, так и для других установленных версий. Например, если у вас установлена версия Visual Studio 2012, то, чтобы указать набор средств Visual C++ 11.0 для Windows XP, добавьте следующий элемент группы свойств в файл проекта Myproject.vcxproj после элемента <Import /> файла Microsoft.Cpp.props .
Чтобы выполнить повторную сборку проекта с использованием набора средств Visual C++ 11.0 для Windows XP, введите следующую команду.
msbuild myproject.vcxproj /p:PlatformToolset=v110_xp /t:rebuild
Добавление настроек MSBuild
MSBuild предоставляет различные способы настройки процесса сборки. В этих статьях рассказывается о том, как можно добавить пользовательские этапы сборки, средства и события в проект MSBuild.
Как работает MSBuild? В этой статье вы узнаете, как MSBuild обрабатывает файлы проекта, вызываемые из Visual Studio, командной строки или скрипта. Знание работы MSBuild поможет вам лучше диагностировать проблемы и улучшить настройку процесса сборки. В этой статье описывается процесс сборки, который в основном применим ко всем типам проектов.
Запуск
MSBuild можно вызывать из Visual Studio с помощью объектной модели MSBuild в Microsoft.Build.dll или путем вызова исполняемого файла непосредственно в командной строке или в сценарии, например в системах CI. В любом случае входные данные, влияющие на процесс сборки, включают файл проекта (или объект проекта, внутренний для Visual Studio), возможно, файл решения, переменные среды и параметры командной строки или их эквиваленты объектной модели. На этапе запуска параметры командной строки или эквиваленты объектной модели используются для настройки параметров MSBuild, таких как параметры средств ведения журнала. Свойства, заданные в командной строке с помощью параметра -property или -p , задаются как глобальные свойства, которые переопределяют все значения, которые будут установлены в файлах проекта, даже если файлы проекта считываются позже.
В следующих разделах содержатся сведения о входных файлах, таких как файлы решений или файлы проектов.
Проекты и решения
Экземпляры MSBuild могут состоять из одного проекта или нескольких проектов в составе решения. Файл решения не является XML-файлом MSBuild, но MSBuild интерпретирует его для получения сведений о проектах, которые должны быть созданы для заданной конфигурации и параметров платформы. Когда MSBuild обрабатывает эти входные данные XML, это называется сборкой решения. Он имеет несколько расширяемых точек, которые позволяют выполнять какие-либо действия во всех сборках решения, но поскольку эта сборка является отдельным запуском из сборок отдельных проектов, никакие настройки свойств или целевых определений из сборки решения не важны для каждой отдельной сборки проекта.
Дополнительные сведения о том, как расширить сборку решения, можно найти в разделе Настройка сборки решения.
Сборки Visual Studio и сборки MSBuild.exe
Имеется ряд существенных различий между сборкой проектов в Visual Studio и при вызове MSBuild напрямую либо с помощью исполняемого файла MSBuild, либо при использовании объектной модели MSBuild для запуска сборки. Visual Studio управляет порядком сборки проекта для сборок Visual Studio. Он вызывает только MSBuild на уровне отдельного проекта. Когда это происходит, задаются несколько логических свойств ( BuildingInsideVisualStudio и BuildProjectReferences ), которые значительно влияют на то, что делает MSBuild. Внутри каждого проекта выполнение происходит так же, как при вызове с помощью MSBuild, но отличается для проектов, на которые имеются ссылки. В MSBuild, когда требуются проекты, на которые имеются ссылки, возникает фактическая сборка (то есть она запускает задачи и средства и создает выходные данные). Когда сборка Visual Studio находит проект, на который указывает ссылка, MSBuild возвращает ожидаемые выходные данные из упоминаемого проекта. Это позволяет Visual Studio управлять сборкой этих проектов. Visual Studio определяет порядок сборки и вызывает MSBuild отдельно (по мере необходимости), все это полностью находится под контролем Visual Studio.
Другое различие возникает при вызове MSBuild файлом решения, MSBuild анализирует файл решения, создает стандартный входной XML-файл, оценивает его и выполняет в качестве проекта. Сборка решения выполняется перед любым проектом. При сборке из Visual Studio ничего этого не происходит; MSBuild не видит файл решения. Как следствие, настройка сборки решения (с использованием before.SolutionName.sln.targets и after.SolutionName.sln.targets) применяется только к MSBuild.exe или к управляемой объектной модели, а не к сборкам Visual Studio.
Пакеты SDK для проектов
Функция пакета SDK для файлов проекта MSBuild относительно нова. До этого изменения файлы проекта явным образом импортировали файлы TARGETS и PROPS, в которых определен процесс сборки для конкретного типа проекта.
Этап оценки
В этом разделе описывается обработка и анализ этих входных файлов для создания объектов в памяти, определяющих, что будет построено.
Целью этапа оценки является создание в памяти структур объектов, основанных на входных XML-файлах и локальной среде. Фаза оценки состоит из шести этапов обработки входных файлов, таких как XML-файлы проекта и (или) импортированные XML-файлы, которые обычно называются файлами PROPS или TARGETS в зависимости от того, задают ли они свойства или определяют целевые объекты сборки. Каждый проход создает часть объектов в памяти, которые позже используются на этапе выполнения для построения проектов, но на этапе оценки фактические действия сборки не выполняются. Внутри каждого прохода элементы обрабатываются в том порядке, в котором они отображаются.
На этапе оценки передаются следующие этапы.
- Оценка переменных среды.
- Оценка импорта и свойств.
- Оценка определений элементов.
- Оценка элементов.
- Оценка элементов UsingTask.
- Оценка целевых объектов.
Порядок этих проходов имеет значительные последствия. Это важно помнить при настройке файла проекта. См. раздел Порядок оценки свойств и элементов.
Оценка переменных среды
На этом этапе переменные среды используются для установки эквивалентных свойств. Например, переменная среды PATH становится доступной как свойство $(PATH) . При запуске из командной строки или скрипта используется среда команд в обычном режиме. При запуске из Visual Studio используется среда, которая запускается с Visual Studio.
Оценка импорта и свойств
На этом этапе считывается весь входной XML-файл, включая файлы проекта и всю цепочку импорта. MSBuild создает XML-структуру в памяти, которая представляет XML-код проекта и все импортированные файлы. В настоящее время свойства, которые не находятся в целевых объектах, оцениваются и настраиваются.
Как следствие того, что MSBuild считывает все входные XML-файлы на ранних этапах процесса, любые изменения этих входных данных в процессе сборки не влияют на текущую сборку.
Свойства за пределами любого целевого объекта обрабатываются не так, как свойства внутри целевых объектов. На этом этапе оцениваются только свойства, определенные за пределами любого целевого объекта.
Поскольку при проходе свойства обрабатываются по порядку, свойство в любой точке входных данных может обращаться к значениям свойств, которые появляются ранее во входных данных, но не в свойствах, которые появятся позже.
С учетом того, что свойства обрабатываются до оценки элементов, доступ к значению какого-либо элемента во время любой части прохода свойств не дает никакого значения.
Оценка определений элементов
На этом этапе интерпретируются определения элементов и создается представление этих определений в памяти.
Оценка элементов
Элементы, определенные внутри целевого объекта, обрабатываются не так, как элементы за пределами целевого объекта. На этом этапе обрабатываются элементы за пределами целевого объекта и связанные с ними метаданные. Метаданные, заданные определениями элементов, переопределяются метаданными, заданными для элементов. Так как элементы обрабатываются в том порядке, в котором они отображаются, можно ссылаться на элементы, которые были определены ранее, но не на элементы, которые появятся в дальнейшем. По причине того, что элементы передаются после передачи свойств, элементы могут получить доступ к любому свойству, если оно определено за пределами целевых объектов, независимо от того, появляется ли определение свойства позже.
Оценка элементов UsingTask
На этом этапе элементы UsingTask считываются, а задачи объявляются для последующего использования на этапе выполнения.
Оценка целевых объектов
На этом этапе все структуры целевых объектов создаются в памяти в процессе подготовки к выполнению. Фактическое выполнение не происходит.
Этап выполнения
На этапе выполнения целевые объекты упорядочиваются и выполняются вместе с задачами. Но сначала свойства и элементы, определенные в рамках целевых объектов, оцениваются в отношении друг друга в порядке их расположения в рамках одного этапа. Порядок обработки существенно отличается от обработки свойств и элементов, которые не находятся в целевом объекте: сначала все свойства, а затем все элементы в отдельных процессах передачи. Изменения свойств и элементов в целевом объекте можно наблюдать после целевого объекта, в котором они были изменены.
Порядок сборки целевого объекта
В одном проекте целевые объекты выполняются последовательно. Главный вопрос заключается в том, как определить порядок сборки всех элементов, чтобы зависимости использовались для построения целевых объектов в правильном порядке.
Порядок сборки целевого объекта определяется использованием атрибутов BeforeTargets , DependsOnTargets и AfterTargets для каждого целевого объекта. Порядок последующих целевых объектов может зависеть от выполнения более раннего целевого объекта, если предыдущий объект изменяет свойство, на которое имеются ссылки в этих атрибутах.
Правила упорядочивания описаны в разделе Определение порядка сборки целевых объектов. Процесс определяется структурой стека, содержащей целевые объекты для сборки. Целевой объект в верхней части этой задачи начинает выполнение, и если он зависит от какого-либо другого, эти целевые объекты помещаются в начало стека и начинают выполнение. При наличии целевого объекта без зависимостей он выполняется до завершения и его родительский целевой объект возобновляется.
Ссылки проекта
Существует два пути кода, которые MSBuild может использовать: обычный, описанный здесь, и параметр graph, описанный в следующем разделе.
Отдельные проекты задают свои зависимости от других проектов с помощью элементов ProjectReference . Когда проект в верхней части стека начинает сборку, он достигает точки, в которой выполняется целевой объект ResolveProjectReferences , стандартный целевой объект, определенный в общих целевых файлах.
ResolveProjectReferences вызывает задачу MSBuild с входными данными элементов ProjectReference , чтобы получить выходные данные. Элементы ProjectReference преобразуются в локальные элементы, такие как Reference . Этапы выполнения MSBuild для текущего проекта приостанавливаются, когда на этапе выполнения начинается обработка проекта, на который указывает ссылка (этап оценки выполняется в первую очередь по мере необходимости). Проект, на который указывает ссылка, создается только после начала выполнения сборки зависимого проекта и поэтому создает дерево построения проектов.
Visual Studio позволяет создавать зависимости проектов в файлах решения (SLN). Зависимости указываются в файле решения и учитываются только при создании решения или при построении в Visual Studio. При построении одного проекта зависимость этого типа игнорируется. Ссылки на решения преобразуются в элементы ProjectReference , а затем обрабатываются аналогичным образом.
Параметр Graph
Если указать параметр построения Graph ( -graphBuild или -graph ), ProjectReference станет концепцией первого класса, используемой MSBuild. MSBuild будет анализировать все проекты и создавать диаграмму порядка сборки, фактический граф зависимостей проектов, который затем обрабатывается для определения порядка сборки. Как и в случае с целевыми объектами в отдельных проектах, MSBuild гарантирует, что проекты со ссылками создаются после проектов, от которых они зависят.
Параллельное выполнение
Если используется многопроцессорная поддержка (параметры -maxCpuCount или -m ), MSBuild создает узлы, которые являются процессами MSBuild, которые используют доступные ядра ЦП. Каждый проект отправляется на доступный узел. В пределах узла отдельные сборки проекта выполняются последовательно.
Задачи можно выполнять параллельно, указав логическую переменную BuildInParallel, которая задается в соответствии со значением свойства $(BuildInParallel) в MSBuild. В случае задач, для которых разрешено параллельное выполнение, планировщик работы управляет узлами и назначает им работу.
Стандартные импорты
Целевой объект CoreBuild содержит вызовы средств сборки следующим образом:
Эти целевые объекты описаны в следующей таблице. Некоторые целевые объекты применимы только к определенным типам проектов.
| целевого объекта | Описание |
|---|---|
| BuildOnlySettings | Параметры только для реальных сборок, а не для тех случаев, когда MSBuild вызывается при загрузке проекта Visual Studio. |
| PrepareForBuild | Подготовка необходимых компонентов для сборки. |
| PreBuildEvent | Точка расширения проектов для определения задач, выполняемых перед сборкой. |
| ResolveProjectReferences | Анализ зависимостей проекта и сборка проектов, на которые имеются ссылки. |
| ResolveAssemblyReferences | Нахождение сборок, на которые указывают ссылки. |
| ResolveReferences | Состоит из ResolveProjectReferences и ResolveAssemblyReferences для поиска всех зависимостей. |
| PrepareResources | Файлы ресурсов процесса. |
| ResolveKeySource | Разрешает ключ строгого имени, используемый для подписания сборки, и сертификат, используемый для подписи манифестов ClickOnce. |
| Компилятор | Вызывает компилятор. |
| ExportWindowsMDFile | Создает файл WinMD из файлов WinMDModule, сгенерированных компилятором. |
| UnmanagedUnregistration | Удаляет или очищает записи реестра СOM-взаимодействия из предыдущей сборки. |
| GenerateSerializationAssemblies | Создает сборку XML-сериализации с помощью SGen.exe. |
| CreateSatelliteAssemblies | Создает одну вспомогательную сборку для каждого уникального языка и региональных параметров в ресурсах. |
| GenerateManifests | Создает манифест приложения и развертывания ClickOnce или собственный манифест. |
| GetTargetPath | Возвращает элемент, содержащий продукт сборки (исполняемый файл или сборку) для этого проекта с метаданными. |
| PrepareForRun | Копирует выходные данные сборки в окончательный каталог, если они были изменены. |
| UnmanagedRegistration | Настраивает записи реестра для COM-взаимодействия. |
| IncrementalClean | Удаляет файлы, созданные в предыдущей сборке, но не созданные в текущей. Это необходимо для того, чтобы Clean работал в инкрементных сборках. |
| PostBuildEvent | Точка расширения проектов для определения задач, выполняемых после сборки. |
Настраиваемые пользователем импорты
В дополнение к стандартным операциям импорта существует несколько импортов, которые можно добавить для настройки процесса сборки.
- Directory.Build.Props
- Directory.Build.targets
Эти файлы считываются стандартными импортами для всех проектов в любой вложенной папке. Это обычно происходит на уровне решения для настройки управления всеми проектами в решении, но также может располагаться выше в файловой системе, вплоть до корневого каталога диска.
Настройки в файле проекта
Visual Studio обновляет файлы проекта при внесении изменений в обозревателе решений, окнах Свойства или Свойства проекта, но вносить собственные изменения можно также, непосредственно редактируя файл проекта.
Многие модели поведения сборки можно настроить, установив свойства MSBuild либо в файле проекта для локальных настроек проекта, либо, как упоминалось в предыдущем разделе, создав файл Directory.Build.props для глобального задания свойств целых папок проектов и решений. Для нерегламентированных сборок в командной строке или скриптах можно также использовать параметр /p в командной строке, чтобы задать свойства для конкретного вызова MSBuild. Сведения о свойствах, которые можно задать, см. в статье Общие свойства проектов MSBuild.
Следующие шаги
Процесс MSBuild имеет несколько других точек расширения, кроме описанных здесь. Дополнительные сведения см. в статье Настройка сборки и Практическое руководство. Расширение процесса сборки Visual Studio.
Вслед за замечательными анонсами с конференции Connect 2015 мы продолжаем знакомить вас со сценариями использования новых технологий и сервисов для организации непрерывной разработки и тестирования ваших приложений.
Недавно мы рассказывали о реализации непрерывных процессов разработки и тестирования с помощью Visual Studio Team Services (ранее Visual Studio Online). В статье подробно описывается как на базе репозиториев Git в Visual Studio Team Services организовать процесс разработки на базе Scrum и с помощью интеграции с Visual Studio обеспечить непрерывные процесс тестирования и разработки кода (Continuous Integration & Testing).
Предварительная настройка
Предполагается, что у вас уже создана учетная запись Visual Studio Team Services. Если это не так, то обратитесь к онлайн-руководству по регистрации.
Для начала со страницы загрузки компонент нового сборщика установите Windows-агент, который позволит собирать проекты Windows, Azure и другие проекты Visual Studio, а так же проекты Java и Android. Для установки вам потребуется перейти по адресу:
и загрузить агент локально. После установки (скажем, в папку C:\Agent) необходимо запустить от имени администратора C:\Agent\ConfigureAgent.cmd. Другие шаги и подробности читайте по ссылке.
Создание проекта Visual Studio Team Services
В Visual Studio Team Services создайте командный проект, в моем случае – VsoCdDemo (рисунок 1).
Рис.1. – Создание командного проекта в Visual Studio Team Services
Подключение Visual Studio Team Services в Visual Studio 2015
В Visual Studio 2015 в панели Team Explorer подключитесь к вашему командному проекту (рисунок 2)
Рис. 2. – Выбор командного проекта
После подключения вам будет предложено клонировать пока еще пустой репозиторий командного проекта (рисунок 3).
Рис. 3. – Панель Team Explorer в Visual Studio 2015
Создание проекта в Visual Studio 2015
Рис. 5. – Выполнение коммита и пуш в репозиторий
После коммита с действием пуш вы можете увидеть ваш код в репозитории Visual Studio Team Services перейдя на вкладку Code (рисунок 6).
Рис. 6. – Содержимое репозитория в Visual Studio Team Services
Пришло время настроить процесс непрерывной сборки и публикации в Azure (или любое другое место).
Настройка процесса сборки
В Visual Studio Team Services перейдите на вкладку Build и нажите кнопку Actions (зеленый плюс). В окне выберите Visual Studio в качестве шаблона определения сборки (рисунок 7).
Рис. 7. – Шаблоны определения сборки
В следующем окне (рисунок 8) убедитесь что выбран верный тип репозитория, сам репозиторий и перейдя по ссылке Manage убедитесь что у вас правильно настроен Агент сборки. Важно! Укажите галочкой на необходимость включения непрерывной интеграции – тогда после каждого чекина кода будет запускаться наш процесс сборки и публикации.
Рис. 8 – Настройка шаблона сборки
В итоге вы получите следующий настроенный порядок сборки вашего проекта (рисунок 9). В нем заранее определены следующие шаги: Visual Studio Build для сборки решения, шаг тестирования для запуска тестов, шаг публикации символьных файлов и шаг публикации результатов сборки.
Рис. 9. – Работа с шагами процесса сборки и публикации
Для нас с вами ценность представляет только первый шаг – Visual Studio Build, остальные три шага мы будет настраивать по своему, так что вы можете их удалить или выключить.
Давайте попробуем собрать наш проект, для этого выберите первый шаг и заполните параметры сборки (рисунок 10):
— выберите в качестве решения для сборки файл вашего проекта;
— укажите дополнительные аргументы сборки (учтите имя своего проекта):
/t:Build,FileSystemPublish /p:PublishConfiguration=$(BuildConfiguration) /p:PublishOutputPathNoTrailingSlash=$(Build.SourcesDirectory)\AspNetCdDemo\artifacts\bin\$(BuildConfiguration)\Publish
Рис. 10. – Настройка шага сборки
Нажмите на Save и затем на Queue Build для запуска сборки. Вы получите доступ к консоли выполнения команд сборщика, в которой будет происходить сборка. Увы наше решение не сможет собраться и вы увидите следующую ошибку (рисунок 11).
Рис. 11. – Результат сборки с ошибками
Ошибка с которой мы столкнулись – необходимость настройки среды DNX перед сборкой проекта. Для этого нам потребуется более тонкая настройка сборки.
Для использования этого скрипта нам необходимо добавить в решение в Visual Studio 2015 новый файл Prebuild.ps1 в папку Solution Items, скопируйте текст скрипта в этот файл.
Благодаря гибким возможностям нового механизма сборки Visual Studio Team Services мы можем добавлять разнообразные шаги в порядок сборщика, в том числе вызывать необходимые скрипты PowerShell. Вернитесь в определение сборки (рисунок 12)
Рис. 12. – Редактирование описания шагов сборки
И добавьте новый шаг для сборщика, вызвав окно добавления кнопкой “Add build step”. Просто пробегитесь по списку и убедитесь как много встроенных возможностей существует для определения сборки в Visual Studio Team Services (рисунок 13).
Рис. 13. – Галерея возможных шагов сборки
Выберите шаг PowerShell и добавьте его в процесс сборки. Перетащите шаг PowerShell вверх сделав его самым первым для того, чтобы задать очередность выполнения (рисунок 14). В настройках шага PowerShell укажите путь до скрипта: в моем случае это AspNetCdDemo/Prebuild.ps1.
Рис. 14. – Редактирование шага сборки PowerShell
Так как мы настраиваем DNX самостоятельно и восстанавливаем пакеты тоже самостоятельно, то в шаге Visual Studio Build снимите галочку “Restore NuGet Packages”.
Сохраните определение сборки.
Из Visual Studio 2015 отправьте добавленный скрипт Prebuild.ps1 коммитом и пушем в репозиторий. Пройдет пара минут и мы увидим как благодаря нашим шагам автоматически развертывает DNX и все зависимости, как загружаются и устанавливаются пакеты NuGet.
Однако сборка все равно завершилась с ошибкой (рисунок 15).
Рис. 15. – Сборка выполнилась с ошибкой
Рис. 16. – Выполнение сборки без ошибок
Непрерывная публикация в Azure Web App
Рис. 17. – Создание Azure Web App в новом портале
В Visual Studio 2015 добавьте в свой проект в папку Solutions Items новый файл PublishAspNet5Website.ps1 и скопируйте в него содержимое скрипта.
В списке шагов сборки добавьте еще один шаг, на этот раз — Azure PowerShell Script. Вам потребуется настроить параметры вашей подписки Azure для этого перейдите по ссылке Manage и добавьте новый сервис через New Service Endpoint (рисунок 18).
Рис. 18. – Ввод параметров подписки Azure
Вернувшись в настройки шага для скрипта Azure PowerShell выберите добавленную подписку и укажите параметры (рисунок 19):
— путь к скрипту: AspNetCdDemo/PublishAspNet5Website.ps1
— аргументы скрипта (обратите внимание на имя Web App в Azure и название вашего проекта):
-websiteName AzureCdDemo -packOutput $(Build.SourcesDirectory)\AspNetCdDemo\artifacts\bin\$(BuildConfiguration)\Publish
Рис. 19. – Настройка шага сборки Azure PowerShell
Из Visual Studio 2015 выполните коммит и пуш вашего нового скрипта.
Запустится очередной процесс сборки, который на этот раз завершится публикацией проекта в Azure Web App (рисунок 20).
Рис. 20. - Сборка и публикация прошла успешно
Рис. 21. – Сайт работающий в Azure
Финальный тест
Перейдите в Visual Studio 2015 и внесите любые изменения. например в файле Views/Shared/_Layout.cshtml измените текст и разметку. Сделайте коммит и пуш этого файла в репозиторий. Отследите автоматический процесс сборки и публикации в Visual Studio Team Services. Обновите сайт и убедитесь что ваши изменения автоматически опубликованы (рисунок 22).
Рис. 22. – Сайт в Azure с изменениями от непрерывного процесса сборки и публикации
Заключение
В заключении хочется сказать, что новый функционал сборки Visual Studio Team Services позволяет собирать проекты любого типа с конфигурированием любой сложности, подключаясь к большому числу сторонних приложений, серверов и фреймворков с заранее сконфигурированными шаблонами.
Читайте также: