Создать build tools for visual studio 2019
Обновлено: 06.07.2024
Версия кода VS: 1.41.1
Версия расширения C / C ++: 0.26.3
Компиляторы: Visual Studio 2019 Developer Command Prompt v16.4.4
(не установлена Visual Studio, только инструменты командной строки)
Самый полезный комментарий
Показанная разрядность компилятора в настоящее время не оказывает никакого влияния на cl.exe в отношении IntelliSense, разрядность которой можно изменить с помощью настроек intelliSenseMode msvc-x64 или msvc-x86.
Все 12 Комментарий
Привет @ pedro-w. Похоже, вы используете «Инструменты сборки для Visual Studio 2019» и у вас не установлена Visual Studio 2019 (предварительная версия). Это верно? Если это так, похоже, что мы не можем правильно определить место установки для инструментов сборки.
Я пытался понять, смогу ли я помочь диагностировать причину самостоятельно, но не могу найти, где в коде он действительно ищет компиляторы. Я предполагаю, что это как-то связано со свойством knownCompilers ?
Я загрузил последний код из этого репо и могу восстановить / отладить его в коде VS. Есть подсказки, с чего начать?
Да, если вы не видите инструментов сборки VS в известных компиляторах, значит, наш серверный компонент с закрытым исходным кодом не может их найти.
Я думал, что теряю свои шарики, когда не могу найти код для установки известных компиляторов! В любом случае, дайте мне знать, могу ли я предоставить дополнительную информацию, чтобы помочь.
Привет @ pedro-w. У меня проблемы с повторением этого. Я создал новую виртуальную машину (без VS), установил VS 2019 Build Tools (с установленными C ++ Build Tools), открыл новую папку в VS Code (без c_cpp_properties.json ), открыл файл .cpp для запуска Расширение C ++ (v0.26.3) для запуска. Затем я выполнил команду C/C++: Edit Configuration (JSON) и увидел, что она заполняет вновь созданный c_cpp_properties.json правильным путем компилятора. Не могли бы вы попробовать описанное выше и посмотреть, получите ли вы те же результаты?
Попытка вышеуказанного и выбор вместо этого C/C++: Edit Configuration (UI) также привели к заполнению правильного пути к компилятору.
Обнаружение компилятора выполняется в нашем родном exe. Мы перебираем все каталоги, найденные по следующему пути: %ProgramData%\Microsoft\VisualStudio\Packages\_Instances . В каждом из этих каталогов мы открываем state.json и ищем installationPath . Мы добавляем к этому пути \VC\Tools\MSVC и ищем там папку, содержащую номер версии (только '.' И числа). В этой папке мы ожидаем найти папки с именами «include» и «bin». Мы ожидаем найти bin/Hostx64/x64/cl.exe и / или bin/Hostx86/x86/cl.exe . Можете ли вы подтвердить, есть ли что-нибудь, что может блокировать любой из этих шагов?
Я проверю новые установки, но мне может потребоваться некоторое время, чтобы настроить виртуальную машину и т. Д.
Могу сразу сказать, что у меня нет указанного вами пути _Instances . Я думаю, это причина, по которой ваш сервер не может найти файл?
Я устанавливал и удалял Visual Studio 2019 Community в прошлом, и, возможно, это вызвало некоторую путаницу в конфигурации.
В любом случае, если я смогу настроить новую виртуальную машину, мы будем надеяться, что это укажет нам правильное направление.
Спасибо за вашу помощь.
Хорошо, я добился некоторого прогресса. Я установил VS-код и инструменты сборки на настоящий компьютер с Windows 10, на котором никогда раньше не было ни того, ни другого. Все заработало, как вы описываете. Я видел, что %ProgramData%\Microsoft\VisualStudio\Packages содержит целую кучу каталогов, названных в честь пакетов (я полагаю), а также каталог _Instances .
Вернувшись на свой компьютер, я нашел другой путь на моем диске D: (у меня есть небольшой SSD C: и большой жесткий диск D :), который был D:\ProgramData\Microsoft\VisualStudio\Packages и здесь я нашел _Instances и все остальное.
Вполне вероятно, что в какой-то момент я сказал установщику VS поместить что-то на D: \, потому что мой диск C: \ был заполнен.
Сам VS Installer, похоже, согласен с этим (а сами инструменты фактически установлены на C :), поэтому я не знаю, входит ли это в их компетенцию или вы?
В любом случае нетрудно просто установить путь компилятора вручную, хотя после того, как вы только что прошли «автоматический» процесс на новом ПК, действительно впечатляет, насколько просто вы это сделали. Спасибо!
MSBuild является платформой сборки для корпорации Майкрософт и Visual Studio. Это практическое руководство содержит вводную информацию о стандартных блоках MSBuild и описывает способы записи и отладки проектов MSBuild, а также управления ими. Здесь рассматриваются следующие вопросы:
создание файла проекта и работа с ним;
использование свойств сборки;
использование элементов сборки.
MSBuild можно запустить в Visual Studio или из командного окна. В этом пошаговом руководстве вы создадите файл проекта MSBuild с помощью Visual Studio. Вы отредактируете файл проекта в Visual Studio и с помощью командного окна выполните сборку проекта и просмотрите результаты.
Установка MSBuild
Если у вас есть Visual Studio, то MSBuild уже установлен. В Visual Studio 2019 и последующих средства сборки устанавливаются в папку установки Visual Studio. Для обычной установки по умолчанию в Windows 10 файл MSBuild.exe находится в папке установки MSBuild\Current\Bin.
Убедитесь, что в установщике выбраны средства MSBuild для используемых рабочих нагрузок, затем нажмите кнопку Установить.
Если у вас есть Visual Studio, то MSBuild уже установлен. В Visual Studio 2022 средства сборки устанавливаются в папку установки Visual Studio. Для обычной установки по умолчанию в Windows 10 файл MSBuild.exe находится в папке установки MSBuild\Current\Bin.
В установщике Visual Studio перейдите в раздел Отдельные компоненты и найдите флажок для MSBuild. Он выбирается автоматически при выборе любой из других рабочих нагрузок для установки.
Создание проекта MSBuild
Создание файла проекта
Откройте Visual Studio и создайте проект.
В поле Имя проекта введите BuildApp . Введите расположение решения, например D:\ .
В поле Имя файла введите BuildApp . Введите расположение решения, например D:\ . Примите параметры по умолчанию Создать каталог для решения (выбран), Добавить в систему управления версиями (не выбран) и Имя решения (BuildApp).
Щелкните ОК или Создать, чтобы создать файл проекта.
Анализ файла проекта
Анализ файла проекта
В обозревателе решений выберите узел проекта BuildApp.
В браузере Свойства обратите внимание, что свойство Файл проекта имеет значение BuildApp.csproj. В именах всех файлов проектов указан суффикс proj. Если вы создали проект Visual Basic, файлу проекта будет задано имя BuildApp.vbproj.
Еще раз щелкните правой кнопкой мыши узел проекта, а затем выберите Изменить BuildApp.csproj.
Файл проекта откроется в редакторе кода.
Для некоторых типов проектов, например C++, необходимо выгрузить проект, прежде чем можно будет открыть и изменить файл проекта. Чтобы выгрузить проект, щелкните правой кнопкой мыши файл проекта и выберите Выгрузить проект.
Целевые объекты и задачи
Файлы проекта представляют собой файлы в формате XML с корневым узлом Проект.
Для проектов не в стиле SDK необходимо указать пространство имен xmlns в элементе "Проект". Если атрибут ToolsVersion присутствует в новом проекте, он должен соответствовать версии MSBuild. Если версия MSBuild вам неизвестна, вы можете получить ее из первых двух чисел в выходных данных следующей командной строки (например, 16.0):
Создание приложения выполняется с помощью элементов Целевой объект и Задача.
Задача — это наименьшая единица работы или, другими словами, атом сборки. Задачи являются независимыми исполняемыми компонентами, которые могут иметь входные и выходные данные. Сейчас в проекте отсутствуют определенные задачи или задачи, на которые существуют ссылки. Процедура добавления задач в файл проекта описывается в следующих разделах. Дополнительные сведения см. в статье о задачах.
Целевой объект представляет собой именованную последовательность задач. Дополнительные сведения см. в статье о целевых объектах.
[это может быть именованная последовательность задач, но крайне важно то, что она представляет собой что-то, что должно быть создано или выполнено, поэтому ее необходимо определить с помощью подхода, ориентированного на цели]
Импортированные файлы вставляются в файл проекта везде, где на них указывает ссылка.
В проектах в стиле SDK вы не увидите этого элемента Import, так как атрибут SDK приводит к неявному импорту этого файла.
MSBuild отслеживает целевые объекты сборки и гарантирует, что каждый целевой объект будет построен не более одного раза.
Добавление целевого объекта и задачи
Добавление целевого объекта и задачи
Добавьте следующие строки в файл проекта сразу после инструкции Import или после начала элемента Project.
Будет создан целевой объект с именем HelloWorld. Обратите внимание, что во время редактирования файла проекта доступна поддержка IntelliSense.
Добавьте строки в целевой объект HelloWorld, чтобы в результате раздел выглядел следующим образом:
Сохраните файл проекта.
Задача Message является одной из многих, входящих в комплект поставки MSBuild. Полный список доступных задач и сведения об их использовании см. в статье Справочные сведения о задачах MSBuild.
Задача Message принимает строковое значение атрибута Text в качестве входных данных и отображает его в устройстве вывода (или записывает его в один или несколько журналов, если применимо). Целевой объект HelloWorld выполняет задачу Message дважды: сначала для отображения Hello, а затем для отображения World.
Создание целевого объекта
Если вы попытаетесь выполнить сборку этого проекта из Visual Studio, определенный вами целевой объект не будет создан. Это связано с тем, что Visual Studio выбирает целевой объект по умолчанию, а это по-прежнему тот объект, который находится в импортированном файле .targets.
Запустите MSBuild из командной строки разработчика для Visual Studio, чтобы создать целевой объект HelloWorld, определенный выше. Используйте параметр -target или -t для выбора целевого объекта.
В следующих разделах мы будем называть командную строку разработчика командным окном.
Создание целевого объекта
Откройте командное окно.
(Windows 10) В поле поиска на панели задач начните вводить имя средства, например dev или developer command prompt . Откроется список установленных приложений, которые соответствуют вашему шаблону поиска.
Если вам нужно найти средство вручную, найдите файл LaunchDevCmd.bat в папке <папка установки Visual Studio>\Common7\Tools.
В командном окне перейдите в папку, содержащую файл проекта. В данном случае это D:\BuildApp\BuildApp.
Выполните команду msbuild с параметром -t:HelloWorld . Будет выбран и создан целевой объект HelloWorld:
Изучите выходные данные в окне командной строки. Вы должны увидеть две строки — Hello и World:
Если вместо них вы видите The target "HelloWorld" does not exist in the project , возможно, вы забыли сохранить файл проекта в редакторе кода. Сохраните файл и повторите попытку.
Переключаясь между редактором кода и командной строкой, можно изменять файл проекта и сразу же видеть результаты.
Свойства сборки
Свойства сборки являются парами "имя — значение", управляющими сборкой. В верхней части файла проекта уже определено несколько свойств сборки:
Все свойства являются дочерними элементами по отношению к элементам PropertyGroup. Имя свойства — это имя дочернего элемента, а значение свойства — это текстовый элемент дочернего элемента. Например, примененная к объекту директива
определяет свойство с именем TargetFrameworkVersion, задавая ему строковое значение "v4.5".
Свойства сборки можно переопределить в любое время. If
появляется далее в файле проекта или в файле, позже импортированном в файл проекта, свойство TargetFrameworkVersion принимает новое значение v3.5.
Анализ значения свойства
Чтобы получить значение свойства, используйте следующий синтаксис, где PropertyName — имя свойства:
С помощью этого синтаксиса проанализируйте некоторые свойства в файле проекта.
Анализ значения свойства
В редакторе кода замените целевой объект HelloWorld следующим кодом:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующие две строки (ваши выходные данные могут отличаться):
Условные свойства
Многие свойства, например Configuration , определяются условно, то есть в элементе свойства отображается атрибут Condition . Условные свойства определяются или переопределяются только в том случае, если условие принимает значение true. Обратите внимание, что неопределенные свойства получают значение по умолчанию — пустую строку. Например, примененная к объекту директива
означает: "Если свойство Configuration еще не определено, определите его и присвойте ему значение Debug".
Атрибут Condition может быть почти у всех элементов MSBuild. Дополнительные сведения об использовании атрибута Condition см. в статье об условиях.
Зарезервированные свойства
MSBuild резервирует некоторые имена свойств для хранения сведений о файле проекта и двоичных файлах MSBuild. Примером зарезервированного свойства является MSBuildToolsPath. Зарезервированные свойства указываются с символом $, как и любое другое свойство. Дополнительные сведения см. в разделе Практическое руководство. Использование ссылки на имя или расположение файла проекта и Зарезервированные и стандартные свойства MSBuild.
Переменные среды
Ссылаться на переменные среды в файлах проектов можно так же, как на свойства сборки. Например, чтобы использовать переменную среды PATH в файле проекта, примените $(Path). Если проект содержит определение свойства с тем же именем, что и у переменной среды, свойство в проекте переопределит значение переменной среды. Дополнительные сведения см. в разделе Практическое руководство. Использование переменных среды в построении.
Задание свойств из командной строки
Свойства можно определить в командной строке с помощью параметра -property или -p. Значения свойств, полученные из командной строки, переопределяют значения свойств, заданные в файле проекта и переменных среды.
Настройка значения свойства из командной строки
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующую строку:
MSBuild создает свойство Configuration и присваивает ему значение Release.
Специальные символы
Некоторые символы имеют особое значение в файлах проекта MSBuild. К ним относятся точка с запятой (;) и звездочка (*). Чтобы использовать эти специальные символы в качестве литералов в файле проекта, их необходимо задать с помощью синтаксиса %<xx>, где <xx> представляет шестнадцатеричное значение ASCII символа.
Измените задачу Message, чтобы отображать значение свойства Configuration со специальными символами для удобства чтения.
Использование специальных символов в задаче Message
В редакторе кода замените обе задачи Message следующей строкой:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующую строку:
Дополнительные сведения см. в статье Специальные символы в MSBuild.
Элементы сборки
Элемент — это часть данных, обычно имя файла, которая используется в качестве входных данных для системы сборки. Например, коллекцию элементов, представляющую исходные файлы, можно передать в задачу Compile, чтобы скомпилировать их в сборку.
Все элементы являются дочерними элементами по отношению к элементам ItemGroup. Именем элемента является имя дочернего элемента, а значением — значение атрибута Include дочернего элемента. Значения элементов с одинаковым именем собираются в типы элементов с таким именем. Например, примененная к объекту директива
определяет группу элементов, содержащую два элемента. Тип элемента Compile имеет два значения: Program.cs и Properties\AssemblyInfo.cs.
Следующий код создает тот же тип элементов посредством объявления обоих файлов в одном атрибуте Include, разделенных точкой с запятой.
Дополнительные сведения см. в разделе Элементы.
Пути к файлам задаются относительно папки, содержащей файл проекта MSBuild, даже если файл проекта является импортированным. Существует несколько исключений, например при использовании элементов Import и UsingTask.
Анализ значений типа элемента
Чтобы получить значения типа элемента, используйте следующий синтаксис, где ItemType — это имя типа элемента:
С помощью этого синтаксиса проанализируйте тип элемента Compile в файле проекта.
Анализ значений типа элемента
В редакторе кода замените целевую задачу HelloWorld следующим кодом:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующую строку:
По умолчанию значения типа элемента разделены точкой с запятой.
Чтобы изменить разделитель типа элемента, используйте следующий синтаксис, где ItemType — это тип элемента, а Separator — это строка из одного или нескольких разделительных символов:
Измените задачу Message для использования символов возврата каретки и перевода строки (%0A%0D) для отображения элементов Compile по одному в строке.
Отображение значений типов элементов по одному в строке
В редакторе кода замените задачу Message следующей строкой:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Должны отобразиться следующие строки:
Атрибуты Include, Exclude и подстановочные знаки
Можно использовать подстановочные знаки "*", "**" и "?" с атрибутом Include, чтобы добавить элементы к типу элемента. Например, примененная к объекту директива
добавляет все файлы с расширением файла .jpg в папке изображений к типу элемента Photos, тогда как
добавляет все файлы с расширением файла .jpg в папке изображений и всех ее вложенных папках к типу элемента Photos. Дополнительные примеры см. в статье Практическое руководство. Выбор файлов для сборки.
Обратите внимание, что, так как элементы объявлены, они добавляются к типу элемента. Например, примененная к объекту директива
создает тип элемента Photo, содержащий все файлы в папке изображений с расширением .jpg или .jpg. Это эквивалентно следующей строке:
С помощью атрибута Exclude можно исключить элемент из типа элемента. Например, примененная к объекту директива
добавляет все файлы с расширением .cs в тип элемента Compile, за исключением файлов, имена которых содержат строку Designer. Дополнительные примеры см. в статье Практическое руководство. Исключение файлов из сборки.
Атрибут Exclude применяется только к элементам, добавленным с помощью атрибута Include в элемент, содержащий их оба. Например, примененная к объекту директива
не исключит файл Form1.cs, добавленный в предыдущий элемент.
Включение и исключение элементов
В редакторе кода замените задачу Message следующей строкой:
Добавьте эту группу элементов сразу после элемента Import:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующую строку:
Метаданные элементов
Помимо сведений, собранных из атрибутов Include и Exclude, элементы могут содержать метаданные. Эти метаданные могут использоваться задачами, требующими дополнительных сведений об элементах, а не просто их значений.
Для объявления элементов в файле проекта создается элемент с именем метаданных, являющийся дочерним по отношению к элементу. Элемент может содержать нуль или более значений метаданных. Например, следующий элемент CSFile содержит метаданные Culture со значением Fr:
Чтобы получить значение метаданных типа элемента, используйте следующий синтаксис, где ItemType — это имя типа элементов, а MetaDataName — имя метаданных:
Анализ метаданных элементов
В редакторе кода замените задачу Message следующей строкой:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Должны отобразиться следующие строки:
Обратите внимание, что фраза Compile.DependentUpon появляется несколько раз. Использование метаданных с таким синтаксисом в целевом объекте приводит к пакетной обработке. Пакетная обработка означает, что задачи в целевом объекте выполняются один раз для каждого уникального значения метаданных. Это является эквивалентом скрипта MSBuild общей конструкции программирования for loop. Дополнительные сведения см. в статье Пакетная обработка.
Стандартные метаданные
Всякий раз, когда элемент добавляется в список элементов, ему назначаются некоторые стандартные метаданные. Например %(Filename) возвращает имя файла любого элемента. Полный список стандартных метаданных см. в статье Общеизвестные метаданные элементов MSBuild.
Анализ стандартных метаданных
В редакторе кода замените задачу Message следующей строкой:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Должны отобразиться следующие строки:
Сравнивая два приведенных выше примера, можно увидеть, что, хотя не у каждого элемента в типе элемента Compile имеются метаданные DependentUpon, у всех элементов есть стандартные метаданные Filename.
Преобразования метаданных
Списки элементов могут быть преобразованы в новые списки элементов. Чтобы преобразовать список элементов, используйте следующий синтаксис, где <ItemType> — это имя типа элементов, а <MetadataName> — имя метаданных:
Например, список элементов исходных файлов можно преобразовать в коллекцию объектных файлов с помощью выражения @(SourceFiles -> '%(Filename).obj') . Дополнительные сведения см. в статье Преобразования.
Преобразование элементов с помощью метаданных
В редакторе кода замените задачу Message следующей строкой:
Сохраните файл проекта.
В командном окне введите и выполните следующую строку:
Проанализируйте результат. Вы должны увидеть следующую строку:
Обратите внимание, что выраженные в этом синтаксисе метаданные не приводят к пакетной обработке.
Следующие шаги
Пошаговые инструкции по созданию файла простого проекта см. в статье Пошаговое руководство. Создание файла проекта MSBuild с нуля.
По натуре своей многие разработчики слишком ленивые не любят делать одно и то же действие много раз. Нам проще научить компьютер, чтобы он делал монотонные действия за нас.
Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит 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 шаблоны для проставления версий: номер версии собиралась из содержимого файла в формате <major>.<minor>.<revision> , далее к ней добавлялся номер сборки из 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:
![Не забывайте пересоздавать ветки от develop]()
(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не забываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.
Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:
Как это работает:
- Мы проставляем метки в формате <major>.<minor>.<revision> .
- Тогда git describe --long возвращает нам строку, описывающую версию в формате <major>.<minor>.<revision>-<количество новых коммитов>-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:
Visual Studio2019 + конфигурация компиляции Cmake OpenCV4.1.2 + Contrib4.1.2 (два)
![]()
Предисловие: В этой статье в качестве примера используется OpenCV41.2. Некоторые пакеты функций opencv существуют в виде сторонних разработчиков и объединены в opencv_contrib-4.1.2. Как объединить функции всего contrib и самого OpenCV для компиляции? Эта статья - результат моей собственной работы. Она похожа на многие учебные пособия в Интернете. После завершения компиляции, как ее использовать, обратитесь к предыдущему использованию OpenCV в VS:
1. Скачивание исходного кода и установка необходимого программного обеспечения.
1.1 Загрузка исходного кода
1.2 Установка необходимого программного обеспечения
После завершения установки здесь не будет повторяться настройка переменных среды.
Во-вторых, конфигурация, связанная с Cmake
Мой адрес распаковки исходного кода:
Адрес распаковки OpenCV: D: \ OpenCV_Contrib_Source \ opencv4.1.2 \ opencv-4.1.2
Содержимое класса внутри выглядит следующим образом:
![]()
Адрес распаковки OpenCV_contrib: D: \ OpenCV_Contrib_Source \ opencv_contrib-4.1.2
Содержимое класса внутри выглядит следующим образом:
![]()
Где мне скомпилировать проект OpenCV? Например, я скомпилировал в следующую папку:
2.1 Первый шаг настройки
Откройте cmake-gui, установите его следующим образом и нажмите кнопку «Настроить»:
![]()
После завершения первого шага настройки вы получите следующий интерфейс:
![]()
2.2 Второй шаг настройки
Снова нажмите кнопку «Настроить», и красный интерфейс наверху станет белым. Здесь я не особо понимаю, почему это нужно делать дважды, это должен быть второй раз для проверки. Если кто-то знает, я надеюсь сообщить вам следующее:
![]()
Среди них мы можем взглянуть на информацию о конфигурации, сгенерированную ниже, что именно это такое:
Фактически это информация о локальном компьютере, ЦП и различных версиях, таких как версия C ++, версия Python, версия Java и т. Д. Окончательная версия OpenCV будет установлена в:
2.3 Третий шаг Generate (два маленьких шага)
(1) Проверить BUILD_opencv_world
![]()
Начиная с версии openCV 3, одним из наиболее удобных мест является интеграция множества библиотек в один opencv_xxxworld.lib, в противном случае будет сгенерировано много файлов библиотеки, поэтому, когда мы пишем программы, на этапе компоновки необходимо связать несколько библиотек Библиотеки, неудобные, теперь все интегрированы в world.lib, нам нужно только установить ссылку на этот. Когда мы нажимаем Configure, нам нужно найти параметр BUILD_opencv_world и проверить его.В противном случае, если вы не отметите его и не нажмете Generate, он все равно будет генерировать много независимых зависимых библиотек, что не очень удобно при вызове add.
(2) Настройте OPENCV_EXTRA_MODULES_PATH
![]()
Фактически, исходный код каждого модуля в OpenCV_contrib также добавляется для совместной компиляции.
После выполнения двух частей нажмите кнопку «Создать», когда в разделе «Cmake» вы увидите
Когда информация отображается, это означает, что Cmake успешно выполнил этот шаг.
Три, компиляция VS2019 (компиляция релизной версии)
Сначала посмотрим на сборку релизной версии:
![]()
Перейдите в целевую папку: D: \ Program Files \ Opencv4.1.2
Откройте решение OpenCV.sln с помощью vs2019
Мы обнаружили, что есть много проектов и файлов проектов xxx.vcxproj file
Здесь много способов работы, в основном три, на самом деле все они имеют одно и то же значение
Сначала сгенерируйте ALL_BUILD, затем УСТАНОВИТЕ
(1) Метод 1:
Сгенерируйте все решение напрямую:Создать / сгенерировать решение
Затем выборочно сгенерируйте INSTALL: найдите CmakeTargets в обозревателе решений, щелкните, чтобы найти INSTALL,«Щелкните правой кнопкой мыши / Только для проекта / Создать только INSTALL»
(2) Метод второй ：
Сначала сгенерируйте ALL_BUILD напрямую, найдите CmakeTargets в обозревателе решений и щелкните, чтобы найти ALL_BUILD:"Щелкните правой кнопкой мыши / Создать"
Затем выборочно сгенерируйте INSTALL: найдите CmakeTargets в обозревателе решений, щелкните, чтобы найти INSTALL,«Щелкните правой кнопкой мыши / Только для проекта / Создать только INSTALL»
(3) Метод третий:
Завершите генерацию ALL_BUILD и INSTALL за один раз
Выполнение заказа«Генерация / Пакетное создание», Откройте следующее диалоговое окно, выберите ALL_BUILD и INSTALL, как показано ниже:
![]()
Это может занять много времени, в основном потому, что генерация ALL_BUILD занимает много времени. Подождите, пока не завершится компиляция и не завершится отображение.
Это означает успех. В этот раз мы открываем папку установки, упомянутую ранее, а именно
Получите следующие файлы
Мы обнаружили, что это то же самое, что и прямая загрузка скомпилированного файла окна самостоятельно. Содержание сравнивается следующим образом:
![]()
![]()
Но разница в том, что Windows была скомпилирована и содержит только стандартную часть OpenCV, сторонний вклад не включил ее, но включены наши собственные варианты, поэтому мы находим файл
Сравнение показывает, что размеры у них разные, один - всего 2442 КБ, а другой - 3962 КБ.
Четыре, компиляция VS2019 (компиляция релизной версии)
Метод компиляции тот же, вам нужно только запрограммировать выпуск на отладку, но компиляция отладочной версии может вызвать следующие ошибки:
В процессе компиляции python37_d.lib, python36_d.lib или python27_d.lib не будут найдены.
![]()
Пять, используйте
См. Предыдущую статью
Примечания: Компиляция OpenCV в окне - действительно громоздкая и утомительная вещь, и, по всей вероятности, добиться успеха в ней сложно. Возможно, вы столкнетесь с различными проблемами после этой процедуры, как она есть. Это нормально.
Интеллектуальная рекомендация
![]()
[Makefile от более мелких к более глубоким полная запись обучения 4] Переменные и различные методы присвоения
Давайте сегодня узнаем о различных методах присваивания переменных в Makefile! Смысл тяжелой работы, чтобы бедность больше не ограничивать свое воображение! Добавьте QQ, чтобы вместе учиться и обменив.
[Luogu P3147] [BZOJ 4576] [USACO16OPEN]262144
Портал Луогу БЗОЙ Портал Описание заголовка Bessie likes downloading games to play on her cell phone, even though she doesfind the small touch screen rather cumbersome to use with her large hooves. Sh.
Читайте также:
