Visual studio настройка сборки
В наше время open source проекты все популярнее. На площадках открытых проектов, например, на github можно найти множество полезных программ, но они не всегда имеют исполняемые файлы ("exe"), поэтому я постараюсь рассказать о том, как можно собрать самостоятельно C/C++ программу, из исходников, написанную на Microsoft Visual Studio.
Первым делом нам необходимо загрузить онлайн установщик Microsoft Visual Studio, с официального сайта. Для компиляции С/С++ проектов нет необходимости во всех пакетах и можно выбрать только те, которые нам необходимы.
Установщик загрузит необходимые пакеты из интернета и установит их.
После установки Visual Studio можно убедиться, что всё работает создав тестовый проект и скомпилировав его. Для этого нажмите в меню "Файл" → "Создать" → "Проект. "
После чего появится диалог выбора типа проекта, где можно выбрать:
- Консольное приложение;
- Классическое приложение;
- Библиотеку динамической компоновки (dll);
- Статическую библиотеку;
В нашем случае для быстрой проверки подойдет консольное приложение, выбираем название и папку проекта , после чего жмём кнопку "ОК" и создается наша программа.
После этого остается остается лишь скомпилировать её, для этого нужно выбрать в меню "Сборка" и нажать на пункт "Собрать решение".
Далее наш проект скомпилируется и в папке проекта появится наш тестовый исполняемый файл ("exe").
Если всё работает как надо, то можно приступать к сборке какого-нибудь другого открытого проекта с github или другого хостинга проектов.
Первым делом нам нужно загрузить исходники проекта. На площадке github это делается довольно просто, жмем на кнопку "Code" и "Download ZIP". После чего нужно распаковать его и можно приступать к сборке.
Ищем файл с расширением ".vcxproj" и запускаем его. Перед нами появится диалог в котором нам предложат обновить SDK проекта (набор библиотек для разработки, которые Microsoft периодически обновляет) и набор инструментов, жмём обновить.
Теперь наш проект можно собрать, но до сборки необходимо выбрать разрядность проекта (например, для 32 битной системы или 64 битной), а также тип сборки (отладочный режим - debug или release).
Выбираем 64 битную систему и тип сборки релиз, после чего компилируем проект. Как и ранее нужно выбрать в меню "Сборка" и нажать на пункт "Собрать решение".
Некоторые проектам требуется вручную изменить SDK и набор инструментов, на установленный у вас, для этого идём в свойства проекта, выбираем сверху типа сборки и разрядность системы и уже там изменяем SDK и набор инструментов. В выпадающем меню появляются установленные у нас версии, выбираем их и нажимаем "ОК". После чего наш проект скомпилируется.
Бывает, что проект использует сторонние библиотеки, для этого их нужно загрузить отдельно и положить в папку. Узнать путь или изменить его можно в свойстве проекта, в разделе "С/C++" → "Общие" → "Дополнительные каталоги включаемых файлов".
Бывает, что SDK или набор инструментов, в свойстве проекта не изменяется в диалоге, чтобы изменить их нужно записать номер SDK, закрыть Visual Studio и вручную, блокнотом изменить этот номер в файле проекта ".vcxproj".
При возникновении других проблем можно попробовать их загуглить, возможно, что кто-то уже сталкивался с ними и решил их.
В этой статье описываются некоторые параметры, которые можно настроить при создании приложений с помощью Visual Studio. Вы создадите настраиваемую конфигурацию сборки, скроете определенные предупреждения и расширите выходные данные сборки для примера приложения.
Установите пример приложения
Создание настраиваемой конфигурации сборки
При создании решения конфигурации отладочной сборки и сборки выпуска и их целевые платформы по умолчанию определяются для решения автоматически. Затем вы можете настроить эти конфигурации или создать собственные. Конфигурации указывают тип сборки. Целевые платформы указывают операционную систему, на которое ориентировано приложение для этой конфигурации. См. дополнительные сведения о конфигурациях сборки, платформах сборки и конфигурациях отладки и выпуска проекта.
Конфигурации и параметры платформы можно изменять или создавать с помощью диалогового окна Диспетчер конфигураций. В этой процедуре вы создадите конфигурацию сборки для тестирования.
Создание конфигурации сборки
Откройте диалоговое окно Диспетчер конфигураций.
В списке Активная конфигурация решения выберите .
В диалоговом окне Создание конфигурации решения введите для новой конфигурации имя Test , скопируйте параметры из существующей конфигурации Отладка и нажмите кнопку ОК.
В списке Активная платформа решения выберите .
В диалоговом окне Создание платформы решения выберите x64 и не копируйте параметры из платформы x86.
Активная конфигурация решения была изменена на Тест, а для активной платформы решения задано значение x64.
Активную конфигурацию решения можно быстро проверить или изменить с помощью списка Конфигурации решения на панели инструментов Стандартная.
создание приложения;
Далее вам предстоит создать решение с помощью настраиваемой конфигурации сборки.
Выполните сборку решения.
В строке меню последовательно выберите Сборка > Собрать решение (или нажмите CTRL+SHIFT+B).
Окно Вывод отображает результат сборки. Сборка успешно завершена.
Скрытие предупреждений компилятора
Далее мы добавим код, который приводит к созданию предупреждения компилятором.
В проекте Visual Basic откройте файл ExpenseReportPage.xaml.vb. В пользовательском конструкторе Public Sub New. добавьте следующий код: Dim i .
Окно Вывод отображает результат сборки. Сборка была выполнена успешно, но были созданы предупреждения:
Вы можете временно скрыть некоторые предупреждения во время сборки, чтобы они не засоряли выходные данные сборки.
В обозревателе решений выберите узел проекта верхнего уровня.
Открывается Конструктор проектов.
Выберите страницу Сборка и затем в поле Отключить предупреждения укажите номер предупреждения 0168.
Окно Вывод отображает только сводные данные о сборке.
Отключение всех предупреждений сборки в Visual Basic
В обозревателе решений выберите узел проекта верхнего уровня.
Открывается Конструктор проектов.
На странице Компиляция установите флажок Выключить все предупреждения.
Окно Вывод отображает только сводные данные о сборке.
Отображение дополнительных сведений о сборке в окне вывода
Вы можете изменить объем информации, отображаемый о процессе сборки в окне Вывод. В общем случае задан минимальный уровень детализации сборки, при котором в окне Вывод отображается только сводка по процессу сборки вместе с высокоприоритетными предупреждениями или ошибками. Чтобы отобразить дополнительные сведения о сборке, см. раздел Диалоговое окно "Параметры", "Проекты и решения", "Сборка и запуск".
При отображении дополнительных сведений сборка будет занимать больше времени.
Изменение объема сведений в окне вывода
Откройте диалоговое окно Параметры.
Выберите категорию Проекты и решения и затем страницу Сборка и запуск.
В строке меню выберите Сборка > Очистить решение.
Выполните сборку решения и просмотрите сведения в окне Вывод.
Сведения о сборке включают в себя время запуска сборки (находится в начале) и порядок обработки файлов. Они также включают фактический синтаксис компилятора, запускаемый Visual Studio при сборке.
В сборке Visual Basic параметр /nowarn не включает в себя определенные исключаемые предупреждения, поэтому предупреждения не отображаются.
В окне Вывод можно искать содержимое, отобразив диалоговое окно Найти нажатием клавиш CTRL+F.
Создание сборки выпуска
Вы можете создать версию примера приложения, оптимизированную для поставки. Для сборки выпуска вы указываете, что исполняемый файл копируется в общую сетевую папку перед запуском сборки.
Указание сборки выпуска для Visual Basic
Открывается Конструктор проектов.
Откройте вкладку Компиляция.
В списке Конфигурация выберите Выпуск.
В списке Платформа выберите x86.
В поле Выходной путь сборки укажите сетевой путь.
Например, так: \\myserver\builds .
Открывается Конструктор проектов.
Перейдите на страницу Сборка.
В списке Конфигурация выберите Выпуск.
В списке Платформа выберите x86.
В поле Путь для создаваемых файлов укажите сетевой путь.
Например, можно указать \\myserver\builds .
На стандартной панели инструментов выберите в качестве конфигураций решения Выпуск, а в качестве платформ решения — x86.
Исполняемый файл копируется в указанный сетевой путь. Путем к нему будет \\myserver\builds\\FileName.exe .
Добавление аргументов в вызовы командной строки MSBuild для проекта
Directory.Build.props и Directory.Build.targets
В файловых системах на основе Linux учитывается регистр. Убедитесь, что регистр имени файла Directory.Build.props полностью совпадает, иначе он не будет обнаружен во время сборки.
Пример Directory.Build.props
Например, если вы хотите предоставить всем проектам новую функцию Roslyn /deterministic через свойство $(Deterministic) в целевом объекте Roslyn CoreCompile , можно сделать следующее.
Создайте в корне репозитория файл с именем Directory.Build.props.
Добавьте в этот файл приведенный ниже XML-код.
Область поиска
При поиске файла Directory.Build.props MSBuild обходит структуру каталогов вверх от расположения проекта ( $(MSBuildProjectFullPath) ). Когда файл найден, поиск останавливается. Например, если $(MSBuildProjectFullPath) имеет значение c:\users\username\code\test\case1, MSBuild начнет поиск там, а затем будет переходить вверх по структуре каталогов, пока не найдет файл Directory.Build.props. Пример такого поиска по структуре каталогов представлен ниже.
Расположение файла решения не имеет значения для Directory.Build.props.
Порядок импорта
Свойства, которые задаются в файле Directory.Build.props, можно переопределить в любом другом месте файла проекта или в импортируемых файлах. Таким образом, устанавливаемые в файле Directory.Build.props свойства следует рассматривать как настройки по умолчанию для проектов.
Если вам требуется задать свойство или определить целевой объект для отдельного проекта, которые будут переопределять любые ранее произведенные настройки, соответствующую логику следует помещать в файл проекта после окончательного импорта. Чтобы сделать это в проекте в стиле пакета SDK, сначала необходимо заменить атрибут стиля пакета SDK эквивалентными импортируемыми компонентами. См. статью Использование пакетов SDK проекта MSBuild.
Обработчик MSBuild считывает все импортируемые файлы в процессе вычисления до начала выполнения сборки (включая любые PreBuildEvent ) для проекта. Таким образом, эти файлы не должны быть изменены в рамках PreBuildEvent или любой другой части процесса сборки. Любые изменения вступают в силу только после следующего вызова MSBuild.exe или выполнения следующей сборки Visual Studio. Кроме того, если процесс сборки содержит много сборок проекта (как в случае с настройкой для различных версий или сборкой зависимых проектов), импортированные файлы, включая Directory.build.props, считываются при вычислении для каждой отдельной сборки проекта.
Вариант использования: многоуровневое слияние
Предположим, что вы используете следующую стандартную структуру решения:
Допустим, вам нужны некоторые общие свойства для всех проектов (1) , а также общие свойства для проектов исходного кода (2-src) и общие свойства для проектов тестирования (2-test) .
Чтобы система MSBuild правильно объединила "внутренние" файлы (2-src и 2-test) с "внешним" файлом (1), обязательно учитывайте, что MSBuild прекращает сканирование при обнаружении файла Directory.Build.props. Чтобы продолжить сканирование и включить в слияние внешний файл, добавьте в оба внутренних файла следующее:
Ниже кратко описан основной алгоритм работы MSBuild.
- Для каждого проекта MSBuild находит ближайший файл Directory.Build.props, расположенный выше в структуре решения, объединяет его с параметрами по умолчанию и на этом останавливает сканирование.
- Если вы хотите обнаружить и объединить несколько уровней, импортируйте "внешний" файл из "внутреннего", как показано выше ( ).
- Если "внешний" файл сам не импортирует ничего, расположенного выше, то сканирование останавливается на этом этапе.
- Для управления процессом сканирования и слияния используйте $(DirectoryBuildPropsPath) и $(ImportDirectoryBuildProps) .
Проще говоря, MSBuild останавливает поиск на первом файле Directory.Build.props, который ничего не импортирует.
Выбор между добавлением свойств в PROPS-файл и TARGETS-файл
Поведение MSBuild зависит от порядка импорта, то есть всегда используется последнее обработанное определение свойства (или UsingTask , или целевого объекта).
При использовании явных инструкций import вы можете указывать их в любой точке файла .props или .targets. Наиболее распространено следующее соглашение:
файлы .props импортируются на ранних этапах импорта;
файлы .targets импортируются на поздних этапах импорта.
Такое соглашение поддерживается инструкциями import (например, файл Sdk.props импортируется первым, до всего содержимого файла, а файл Sdk.targets — последним, после всего содержимого файла).
При выборе места для размещения свойств используйте следующие рекомендации общего характера.
Для многих свойств нет никакого значения, где они определены,так как они не перезаписываются и считываются только во время выполнения.
Для поведения, которое можно настраивать для отдельного проекта, задавайте значения по умолчанию в файлах .props.
Старайтесь не устанавливать зависимые свойства в файлах .props путем считывания значений, которые могут быть изменены, поскольку такая настройка не будет применяться до того, как MSBuild считает пользовательский проект.
Устанавливайте зависимые свойства в файлах .targets, где уже будут учтены настройки из отдельных проектов.
Если вам нужно переопределить свойства, выполняйте это в файле .targets, после применения всех пользовательских настроек для отдельных проектов. Будьте внимательны при использовании производных свойств, поскольку их также нужно переопределять.
Включайте элементы в файлах .props (по условию значения свойства). Все свойства учитываются раньше, чем любые элементы, поэтому пользовательские настройки свойств для отдельных проектов будут учтены вовремя и позволят пользовательским проектам применить Remove или Update к любым элементам, полученным через операцию импорта.
Определяйте целевые объекты в файлах .targets. Тем не менее, если файл .targets импортируется из пакета SDK, на забывайте, что такой сценарий усложняет переопределение целевых объектов, ведь пользовательский проект по умолчанию не получает возможности переопределить их.
По возможности старайтесь настраивать свойства во время вычисления, а не изменять их внутри целевого объекта. Эта рекомендация упрощает загрузку проекта и понимание его механизма работы.
MSBuildProjectExtensionsPath
Отключение импортов MSBuildProjectExtensionsPath препятствует применению логики сборки, предоставляемой в пакетах NuGet, к проекту. Некоторым пакетам NuGet нужна работающая логика сборки, и если эта возможность отключена, они будут бесполезны.
Файл USER
MSBuildExtensionsPath и MSBuildUserExtensionsPath
Использование этих механизмов расширения затрудняет получение повторяемых сборок на разных компьютерах. Попробуйте использовать конфигурацию, которую можно возвратить в систему управления версиями и предоставить для общего доступа всем разработчикам базы кода.
По соглашению многие файлы базовой логики сборки импортируют
перед своим содержимым и
после него. Это соглашение позволяет установленным пакетам SDK дополнять логику сборки для распространенных типов проектов.
Настраиваемая конфигурация на основе языка проекта
Настройка сборки решения
Подобная настройка сборки решения применяется только к сборкам из командной строки с MSBuild.exe. Она не применяется к сборкам внутри Visual Studio. По этой причине не рекомендуется размещать настройки на уровне решения. Лучшим вариантом для настройки всех проектов в решении является использование файлов Directory.Build.props и Directory.Build.targets в папке решения, как описано в других разделах этой статьи.
Когда система MSBuild выполняет сборку файла решения, она сначала внутренне преобразует его в файл проекта и затем выполняет его сборку. Созданный файл проекта импортирует before..sln.targets до определения каких-либо целевых объектов и after..sln.targets после их импорта, включая целевые объекты, установленные в каталоги $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportBefore и $(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\SolutionFile\ImportAfter .
Сборка решения выполняется отдельно, поэтому заданные здесь параметры не влияют на сборку проекта.
Расположение этих файлов можно указать с помощью следующих свойств MSBuild:
- CustomBeforeMicrosoftCommonProps
- CustomBeforeMicrosoftCommonTargets
- CustomAfterMicrosoftCommonProps
- CustomAfterMicrosoftCommonTargets
- CustomBeforeMicrosoftCSharpTargets
- CustomBeforeMicrosoftVisualBasicTargets
- CustomAfterMicrosoftCSharpTargets
- CustomAfterMicrosoftVisualBasicTargets
Наилучший подход зависит от вашего сценария. Благодаря расширяемости Visual Studio вы можете настроить систему сборки и реализовать механизм для установки настроек и управления ими.
Если у вас есть выделенный сервер сборки и вы хотите убедиться, что определенные целевые объекты всегда будут выполняться во всех сборках соответствующего типа проекта, выполняемого на этом сервере, то целесообразно использовать глобальный пользовательский файл .targets или .props . Если необходимо, чтобы пользовательские целевые объекты выполнялись только при определенных условиях, используйте другое расположение файла и установите путь к этому файлу, задав соответствующее свойство MSBuild в командной строке MSBuild.
Visual Studio использует пользовательские файлы .targets или .props , если находит их в папке MSBuild при сборке любого проекта соответствующего типа. Это может иметь непредвиденные последствия и при неправильном завершении может отключить функцию построения на компьютере для Visual Studio.
Настройка сборок C++
В проектах C++ рассматриваемые выше файлы с расширениями .targets и .props нельзя использовать для переопределения параметров по умолчанию тем же способом. Файл Directory.Build.props импортируется файлом Microsoft.Common.props, который импортируется в Microsoft.Cpp.Default.props . При этом большинство параметров по умолчанию определяется в файле Microsoft.Cpp.props и для некоторых свойств нельзя использовать условие "если еще не определено", поскольку такие свойства уже определены, а для конкретных свойств проекта, определенных в PropertyGroup с Label="Configuration" , значения по умолчанию должны отличаться (см. описание структуры файлов с расширением .vcxproj и .props).
Тем не менее вы можете использовать следующие свойства, чтобы задать автоматический импорт файлов с расширением .props до или после файлов Microsoft.Cpp.* .
- ForceImportAfterCppDefaultProps
- ForceImportBeforeCppProps
- ForceImportAfterCppProps
- ForceImportBeforeCppTargets
- ForceImportAfterCppTargets
Чтобы настроить значения свойств по умолчанию для всех сборок C++, необходимо создать еще один файл .props (например, MyProps.props) и определить свойство ForceImportAfterCppProps в файле Directory.Build.props , указывающем на него.
Файл MyProps.props будет автоматически импортироваться после файла Microsoft.Cpp.props.
Настройка всех сборок C++
Настраивать установку Visual Studio не рекомендуется, поскольку отслеживать вносимые при этом изменения достаточно сложно. Тем не менее, если вы расширяете возможности Visual Studio, чтобы настроить сборки C++ для конкретных платформ, можно создать файлы .targets для каждой платформы и поместить их в соответствующие папки импорта в рамках расширения Visual Studio.
Файл .targets для платформы Win32 Microsoft.Cpp.Win32.targets содержит следующий элемент Import .
Рядом с концом того же файла находится похожий элемент.
Аналогичные элементы импорта существуют и для других целевых платформ в *%ProgramFiles32%\MSBuild\Microsoft.Cpp\v\Platforms*.
После того как вы поместили файл .targets в соответствующую папку ImportAfter для платформы, MSBuild импортирует ваш файл в каждую сборку C++ для этой платформы. При необходимости в нем можно разместить несколько файлов .targets .
Благодаря расширяемости Visual Studio вы можете выполнять дополнительные настройки, например определять новую платформу. Дополнительные сведения см. в статье Расширяемость проектов C++.
Указание пользовательского импорта в командной строке
Для пользовательских .targets , которые необходимо включить в определенную сборку проекта C++, установите одно или оба свойства ForceImportBeforeCppTargets и ForceImportAfterCppTargets в командной строке.
Для глобальных параметров (например, для влияния на все сборки C++ для платформы на сервере сборки) существует два метода. Во-первых, эти свойства можно задать с помощью системной переменной среды, которая всегда задается. Это работает потому, что MSBuild всегда считывает среду и создает (или переопределяет) свойства для всех переменных среды.
В интегрированной среде разработки все сведения, необходимые для построения проекта, предоставляются в виде свойств. Эти сведения включают в себя имя приложения, расширение (например, DLL, EXE, LIB), параметры компилятора, параметры компоновщика, параметры отладчика, настраиваемые этапы сборки и многие другие компоненты. Как правило, для просмотра и изменения этих свойств используются страницы свойств. для доступа к страницам свойств выберите Project свойствапроекта в главном меню или щелкните правой кнопкой мыши узел проекта в обозреватель решений и выберите пункт свойства.
Свойства по умолчанию
При создании проекта система задает значения для различных свойств. Значения по умолчанию варьируются в зависимости от типа проекта и параметров, выбранных в мастере приложений. Например, проект ATL имеет свойства, связанные с MIDL-файлами, но эти свойства отсутствуют в базовом консольном приложении. В области "Общие" на страницах свойств отображаются свойства по умолчанию:
Применение свойств к конфигурациям сборок и целевым платформам
Некоторые свойства, такие как имя приложения, применяются ко всем вариантам сборки и целевым платформам, будь это сборка отладки или выпуска. Однако большинство свойств зависит от конфигурации. Чтобы создать правильный код, компилятор должен иметь как конкретную платформу, в которой будет выполняться программа, так и конкретные параметры компилятора. Поэтому при задании свойства важно обратить внимание на ту конфигурацию и платформу, к которым должно применяться новое значение. Должен ли он применяться только для отладки сборок Win32 или должен также применяться к отладке ARM64 и отладке x64? Например, для свойства оптимизации по умолчанию задано значение максимизировать скорость (/O2) в конфигурации выпуска, но оно отключено в конфигурации отладки.
Вы всегда можете видеть и изменять конфигурацию и платформу, к которым должно применяться значение свойства. На следующем рисунке показаны страницы свойств с элементами управления конфигурацией и сведениями о платформе в верхней части. Если свойство оптимизации задано здесь, оно будет применяться только для отладки сборок Win32, текущей активной конфигурации, как показано красными стрелками.
На следующем рисунке показана та же страница свойств проекта, но конфигурация изменена на выпуск. Обратите внимание на другое значение для свойства "Оптимизация". Кроме того, обратите внимание, что активной конфигурацией по-прежнему является отладка. Здесь вы можете задать свойства для любой конфигурации, а не только активной.
Целевые платформы
Целевая платформа относится к типу устройства и операционной системы, на которых будет выполняться исполняемый файл. Вы можете создать проект для нескольких платформ. Доступные целевые платформы для проектов C++ зависят от типа проекта. В их число входят только Win32, x64, ARM, ARM64, Android и iOS. Целевая платформа X86, которую вы могли заметить в Configuration Manager, идентична Win32 в собственных проектах C++. Win32 означает 32-разрядную версию Windows, а x64 — 64-разрядную. Дополнительные сведения об этих двух платформах см. в разделе Запуск 32-разрядных приложений.
Дополнительные сведения настройке свойств отладочной сборки см. в следующих разделах:
Параметры компилятора и компоновщика C++
Параметры компилятора и компоновщика C++ находятся в узлах C/C++ и Компоновщик на панели слева в разделе Свойства конфигурации. Эти параметры непосредственно преобразуются в параметры командной строки, которые будут переданы компилятору. Чтобы ознакомиться с документацией по конкретному параметру, выберите параметр в центральной области и нажмите клавишу F1. также можно просмотреть документацию по всем параметрам в MSVC параметры компилятора и параметры компоновщика MSVC.
Значения каталога и пути
MSBuild поддерживает использование констант времени компиляции для определенных строковых значений, таких как включаемые каталоги и пути, называемые макросами. макрос может ссылаться на значение, определенное Visual Studio или системой MSBuild, или на значение, определенное пользователем. Макросы выглядят как $(macro-name) или %(item-macro-name) . Они представлены на страницах свойств, на которых можно ссылаться и изменять их с помощью редактора свойств. Вместо жестко запрограммированных значений, таких как пути к каталогам, используйте макросы. Макросы упрощают совместное использование параметров свойств между компьютерами и версиями Visual Studio. Кроме того, можно обеспечить правильное участие в параметрах проекта в наследовании свойств.
На следующем рисунке показаны страницы свойств для проекта Visual Studio C++. в левой области выбрано правило VC++ каталоги , а на правой панели перечислены свойства, связанные с этим правилом. Значения свойств часто являются макросами, например $(VC_SourcePath) :
Для просмотра значений всех доступных макросов можно использовать Редактор свойств .
Предустановленные макросы
Глобальные макросы:
Глобальные макросы применяются ко всем элементам в конфигурации проекта. Глобальный макрос имеет синтаксис $(name) . Пример глобального макроса — свойство $(VCInstallDir) , которое сохраняет корневой каталог установки Visual Studio. Глобальный макрос соответствует элементу PropertyGroup в MSBuild.
Макросы элементов
Макросы элементов имеют синтаксис %(name) . Для файла макрос элемента применяется только к этому файлу, — например, можно использовать, %(AdditionalIncludeDirectories) чтобы указать каталоги включаемых файлов, которые применяются только к конкретному файлу. Этот тип макроса элемента соответствует метаданным ItemGroup в MSBuild. При использовании в контексте конфигурации проекта макрос элемента применяется ко всем файлам определенного типа. Например, свойство конфигурации определений препроцессора C/C++ может принимать макрос элемента, который применяется ко всем cpp-файлам в проекте. Этот тип макроса элемента соответствует метаданным ItemDefinitionGroup в MSBuild. Дополнительные сведения см. в разделе Определения элементов.
Пользовательские макросы
Вы можете создавать пользовательские макросы для использования в качестве переменных в сборках проекта. Например, можно создать пользовательский макрос, предоставляющий значение пользовательскому шагу сборки или пользовательскому средству сборки. Пользовательский макрос — это пара "имя-значение". Для доступа к этому значению в файле проекта используется нотация $(name) .
Пользовательский макрос хранится на странице свойств. если проект еще не содержит страницу свойств, его можно создать, выполнив действия, описанные в разделе общий доступ или повторное использование Visual Studio параметры проекта.
Создание пользовательского макроса
В левой области диалогового окна выберите Пользовательские макросы. В правой области нажмите кнопку Добавить макрос, чтобы открыть диалоговое окно Добавление пользовательского макроса.
В диалоговом окне задайте имя и значение для макроса. Кроме того, можно установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Редактор свойств
Редактор свойств можно использовать для изменения некоторых строковых свойств и выбора макросов в качестве значений. Чтобы открыть редактор свойств, выберите свойство на странице свойств, а затем нажмите кнопку со стрелкой вниз справа. Если раскрывающийся список содержит Правка >, можно выбрать его, чтобы отобразить редактор свойств для этого свойства.
В редакторе свойств можно нажать кнопку Макросы, чтобы просмотреть доступные макросы и их текущие значения. На следующем рисунке показан редактор свойств для свойства Дополнительные каталоги включаемых файлов после нажатия кнопки Макросы. Если установлен флажок наследовать от родительского объекта или проекта по умолчанию и добавить новое значение, то оно добавляется к любому значению, наследуемому в данный момент. Если снять флажок, новое значение заменяет наследуемые значения. В большинстве случаев следует не снимать этот флажок.
Добавление каталога включения к набору каталогов по умолчанию
При добавлении каталога включения в проект важно не переопределять все каталоги по умолчанию. Правильный способ добавления каталога — добавить новый путь, например " C:\MyNewIncludeDir\ ", а затем добавить $(IncludePath) макрос к значению свойства.
Быстрый просмотр и поиск всех свойств
Без префикса:
поиск только в именах свойств (подстрока без учета регистра).
" / " или " - ":
поиск только в параметрах компилятора (префикс без учета регистра)
v :
поиск только в значениях (подстрока без учета регистра).
Задание переменных среды для сборки
компилятор MSVC (cl.exe) распознает определенные переменные среды, в частности LIB ,, LIBPATH PATH и INCLUDE . при построении с помощью интегрированной среды разработки свойства, заданные на странице свойств каталоги VC++ , используются для задания этих переменных среды. если LIB LIBPATH значения, и INCLUDE уже заданы, например Командная строка разработчика, они заменяются значениями соответствующих свойств MSBuild. затем сборка добавляет значение свойства VC++ каталоги исполняемых каталогов в PATH . Для задания пользовательской переменной среды можно создать пользовательский макрос и затем установить флажок Задание данного макроса в качестве переменной среды в среде сборки.
Задание переменных среды для сеанса отладки
В правой области измените параметры проекта Среда или Объединение среды, а затем нажмите кнопку ОК.
Содержание раздела
Совместное или повторное использование параметров проекта Visual Studio
Создание .props файла с настраиваемыми параметрами сборки, которые можно использовать совместно или повторно.
Наследование свойств проекта
Описывает порядок вычисления для .props .targets .vcxproj переменных среды,, файлов и в процессе сборки.
Изменение свойств и целевых объектов без изменения файла проекта
Создание временных параметров сборки без изменения файла проекта.
По натуре своей многие разработчики слишком ленивые не любят делать одно и то же действие много раз. Нам проще научить компьютер, чтобы он делал монотонные действия за нас.
Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:
- Собирает исходный код и установщик приложения
- проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
- В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:
- отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
- публикация файлов в систему автообновления ПО.
Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.
Чтобы настроить Gitlab Runner, выполните следующие шаги:
Далее надо ввести ответы на вопросы мастера регистрации Runner-а:
В процессе своей работы Gitlab CI берёт инструкции о том, что делать в процессе сборки того или иного репозитория из файла .gitlab-ci.yml , который следует создать в корне репозитория.
И последнее: если нам требуется передавать в скрипт значение параметра, который мы не хотим хранить в самом скрипте (например, пароль для подключения куда-либо), мы можем использовать для этого объявление параметров в gitlab. Для этого зайдите в проекте (или в группе проекта) в Settings > CI/CD и найдите раздел Variables. Прописав в нём параметр с именем (key) SAMPLE_PARAMETER, вы сможете получить его значение в в скрипте .gitlab-ci.yml через обращение $env:SAMPLE_PARAMETER.
Также в этом разделе можно настроить передачу введенных параметров только при сборке защищённых веток (галочка Protected) и/или скрытие значения параметра из логов (галочка Masked).
Подробнее о параметрах окружения сборки смотрите в документации к Gitlab CI.
Скрипт, приведённый выше, уже можно использовать для сборки и вызова тестов. Правда, присутствует НО: крайне неудобно прописывать абсолютные пути к разным установкам Visual Studio. К примеру, если на одной билд-машине стоит Visual Studio 2017 BuildTools, а на другой Visual Studio Professional 2019, то такой скрипт будет работать только для одной из двух машин.
К счастью, с версии Visual Studio 2017 появился способ поиска всех инсталляций Visual Studio на компьютере. Для этого существует утилита vswhere, путь к которой не привязан ни к версии Visual Studio, ни к её редакции. А в Visual Studio 2019 (в версии 16.1 или более новой) есть библиотека, которая умеет «трансформировать» консоль Powershell в режим Developer Powershell, в котором уже прописаны пути к утилитам из поставки VS.
Дописываем переменную к секции Variables:
Затем создаём новую секцию before_msbuild якорем enter_vsdevshell и следующим текстом:
И всюду, где нам надо использовать утилиты Visual Studio, добавляем этот якорь. После этого задача сборки начинает выглядеть намного более опрятно:
Результат: мы имеем путь к vswhere.
Результат: в переменную $visualStudioPath записан путь к Visual Studio или пустая строка, если инсталляций Visual Studio не найдено (обработку этой ситуации мы ещё не добавили).
- Команда Import-Module загружает библиотеку Microsoft.VisualStudio.DevShell.dll, в которой прописаны командлеты трансформации консоли Powershell в Developer-консоль. А командлет Join-Path формирует путь к этой библиотеке относительно пути установки Visual Studio.
На этом шаге нам прилетит ошибка, если библиотека Microsoft.VisualStudio.DevShell.dll отсутствует или путь к установке Visual Studio нужной редакции не был найден — Import-Module сообщит, что не может загрузить библиотеку.
Результат: загружен модуль Powershell с командлетом трансформации.
- Запускаем «переделку» консоли в Developer Powershell. Чтобы корректно прописать пути к утилитам, командлету требуется путь к установленной Visual Studio (параметр -VsInstallPath ). А указание SkipAutomaticLocation требует от командлета не менять текущее расположение (без этого параметра путь меняется на \source\repos ).
Результат: мы получили полноценную консоль Developer Powershell с прописанными путями к msbuild и многим другим утилитам, которые можно использовать при сборке.
Раньше мы использовали t4 шаблоны для проставления версий: номер версии собиралась из содержимого файла в формате .. , далее к ней добавлялся номер сборки из Gitlab CI и он передавался в tt-шаблон, добавляющий в решение везде, где требуется, номер версии. Однако некоторое время назад был найден более оптимальный способ — использование команд git tag и git describe .
Команда git tag устанавливает коммиту метку (тэг). Отметить таким образом можно любой коммит в любой момент времени. В отличие от веток, метка не меняется. То есть если после помеченного коммита вы добавите ещё один, метка останется на помеченном коммите. Если попробуете переписать отмеченный коммит командами git rebase или git commit --amend, метка также продолжит указывать на исходный коммит, а не на изменённый. Подробнее о метках смотрите в git book.
Команда git describe , к сожалению, в русскоязычном gitbook не описана. Но работает она примерно так: ищет ближайшего помеченного родителя текущего коммита. Если такого коммита нет — команда возвращает ошибку fatal: No tags can describe '' . А вот если помеченный коммит нашёлся — тогда команда возвращает строку, в которой участвует найденная метка, а также количество коммитов между помеченным и текущим.
Кстати, по этой же причине если вы используете gitflow, после вливания feature-ветки в develop требуется удалить влитую локальную ветку, после чего пересоздать её от свежего develop:
(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не забываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.
Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:
Как это работает:
- Мы проставляем метки в формате .. .
- Тогда git describe --long возвращает нам строку, описывающую версию в формате ..--g .
- Парсим полученную строку через регулярные выражения, выделяя нужные нам части — и записывем части в $versionGroup .
- Преобразовываем четыре найденные подстроки в 4 числа и пишем их в переменные $major , $minor , $patch , $commit , после чего собираем из них строку уже в нужном нам формате.
- Передаём указанную строку в msbuild чтобы он сам проставил версию файлов при сборке.
Обратите внимание: если вы, согласно gitflow, будете отмечать (тэгировать) ветку master после вливания в неё release или hofix, будьте внимательны: до простановки метки автосборка будет вестись относительно последней существующей ветки. Например, сейчас опубликована версия 3.4, а вы создаёте release-ветку для выпуска версии 3.5. Так вот: всё время существования этой ветки, а также после её вливания в master, но до простановки тэга, автосборка будет проставлять версию 3.4.
SonarQube — это мощный инструмент контроля качества кода.
SonarQube имеет бесплатную Community-версию, которая способна проводить полный анализ. Правда, только одной ветки. Чтобы настроить её на контроль качества ветки разработки (develop), требуется выполнить следующие шаги (разумеется, помимо установки и развёртывания сервера SonarQube):
Теперь при каждой сборке ветки develop в SonarQube будет отправляться подробный анализ нашего кода.
На заметку: вообще команда msbuild /t:rebuild полностью пересобирает решение. Вероятно, в большинстве проектов анализ можно было бы встроить прямо в стадию сборки. Но сейчас у нас анализ в отдельной задаче.
Пара слов об использованных параметрах:
Со сборкой более-менее разобрались — теперь приступаем к тестам. Доработаем код прогона тестов, чтобы он:
- сам находил библиотеки с тестами,
- прогонял их пачкой через xUnit,
- вычислял тестовое покрытие через OpenConver,
- отправлял результаты покрытия тестами в SonarQube.
На заметку: обычно в паре с OpenCover используют ReportGenerator, но при наличии SonarQube мы с тем же успехом можем смотреть результаты через его интерфейс.
Для настройки выполним следующие шаги:
- Скачайте OpenCover в виде zip-файла с сайта github.
- Распакуйте содержимое архива в папку. Например, в C:\Tools\OpenCover .
На заметку: эту утилиту также можно скачать на сборочную машину через NuGet, но тогда надо будет чуть по-иному указывать её путь. - Допишите переменные к секции Variables:
- Модифицируйте задачу тестирования ветки разработки (test_job), чтобы она включала и команды вызова OpenCover:
Обратите внимание: в begin-команде запуска sonar scanner-а появился дополнительный параметр — /d:sonar.cs.opencover.reportsPaths .
Читайте также: