Как установить msbuild без visual studio

Обновлено: 31.12.2024

Я пытаюсь перенести решение Visual Studio 2015 на VS 2017 (15.4.1). Хотя проекты компилируются из Visual Studio, если я пытаюсь создать отдельные проекты из командной строки с помощью MSBuild v15, компиляция не выполняется для любого проекта, который ссылается на другой проект в решении.

MSBuild выводит следующее предупреждение, которое, как мне кажется, указывает, что указанный проект не может быть найден:

c: program files (x86) Microsoft Visual Studio 2017 Community MSBuild 15.0 Bin Microsoft.Common.CurrentVersion.targets (1988,5): предупреждение MSB3245: Не удалось устранить эту ссылку. Ожидаемый файл, но получил каталог «D: TestSolution » c: program files (x86) Microsoft Visual Studio 2017 Community MSBuild 15.0 Bin MSBuild.exe "" d: TestSolution ClassLibrary2 ClassLibrary2. csproj " bin". Если эта ссылка требуется для вашего кода, вы можете получить ошибки компиляции. [D: TestSolution ClassLibrary1 ClassLibrary2.csproj]

Я запускаю MSBuild, используя следующую команду:

Действия по воспроизведению:

В Visual Studio 2017 создайте новое решение с двумя библиотеками классов ClassLibrary2 и ClassLibrary2 .
Пусть ClassLibrary2 ссылку ClassLibrary1 , и убедитесь , что код ссылки на Class1 о ClassLibrary1 . Добавьте ссылку, щелкнув правой кнопкой мыши на узле «Зависимости» проекта в обозревателе решений и выберите «Добавить ссылку . » из контекстного меню.
Скомпилируйте проекты из Visual Studio, чтобы убедиться, что они компилируются из Visual Studio.
Удалите MSBuild из командной строки, используя предыдущую команду. Указанное предупреждение не срабатывает.

Class1.cs (7,26): ошибка CS0246: имя типа или пространства имен ClassLibrary1 не может быть найдено (вам не хватает директивы using или ссылки на сборку?) [D: TestSolution ClassLibrary2 ClassLibrary2.csproj]

Файл проекта для ClassLibrary1:

Файл проекта для ClassLibrary2:

Класс1 в ClassLibrary2:

Что я делаю здесь неправильно?

MSBuild 15.0: предупреждение MSB3245: Не удалось решить эту проблему. Ожидаемый файл, но получил каталог " bin"

c: program files (x86) Microsoft Visual Studio 2017 Community MSBuild 15.0 Bin Microsoft.Common.CurrentVersion.targets (1988,5): предупреждение MSB3245: Не удалось устранить эту ссылку. Ожидаемый файл, но получил каталог «D: TestSolution » c: program files (x86) Microsoft Visual Studio 2017 Community MSBuild 15.0 Bin MSBuild.exe "" d: TestSolution ClassLibrary2 ClassLibrary2. csproj " bin". Если эта ссылка требуется для вашего кода, вы можете получить ошибки компиляции. [D: TestSolution ClassLibrary1 ClassLibrary2.csproj]

Я запускаю MSBuild, используя следующую команду:

Действия по воспроизведению:

В Visual Studio 2017 создайте новое решение с двумя библиотеками классов ClassLibrary2 и ClassLibrary2 .
Пусть ClassLibrary2 ссылку ClassLibrary1 , и убедитесь , что код ссылки на Class1 о ClassLibrary1 . Добавьте ссылку, щелкнув правой кнопкой мыши на узле «Зависимости» проекта в обозревателе решений и выберите «Добавить ссылку . » из контекстного меню.
Скомпилируйте проекты из Visual Studio, чтобы убедиться, что они компилируются из Visual Studio.
Удалите MSBuild из командной строки, используя предыдущую команду. Указанное предупреждение не срабатывает.

Class1.cs (7,26): ошибка CS0246: имя типа или пространства имен ClassLibrary1 не может быть найдено (вам не хватает директивы using или ссылки на сборку?) [D: TestSolution ClassLibrary2 ClassLibrary2.csproj]

packages.config и PackageReference

Прежде чем перейти к рассмотрению каждого инструмента для управления пакетами, сделаем небольшое отступление. Видимо так исторически сложилось, что существует два формата хранения информации об установленных пакетах.

Package Manager UI и Package Manager Console

nuget.exe

Установка пакетов для заданного проекта
1. В папке проекта (где лежит файл *.csproj) создайте файл packages.config и добавьте в него информацию о необходимых пакетах. Вот пример такого файла:

<?xml version = "1.0" encoding = "utf-8" ?>
<packages >
<package id = "AForge" version = "2.2.5" targetFramework = "net46" />
<package id = "AForge.Imaging" version = "2.2.5" targetFramework = "net46" />
<package id = "AForge.Math" version = "2.2.5" targetFramework = "net46" />
</packages >

2. Далее в командной строке (обычной cmd.exe) запускаем nuget. При этом в аргументах командной строки обязательно надо указать путь к файлу packages.config и путь к папке, в которую будут установлены пакеты (обычно это папка packages, которая лежит в папке решения):

SolutionDir\ProjectDir> nuget install packages.config -OutputDirectory SolutionDir\packages

Восстановление пакетов для всего решения
Переходим в корневую папку решения и вызываем:

Когда нужно восстановить пакеты, nuget.exe ищет в папках проектов файлы packages.config и считывает из них информацию о том, какие именно пакеты надо установить.

dotnet.exe

Установка пакетов для заданного проекта

SolutionDir\ProjectDir> dotnet add package <PACKAGE_NAME> --package-directory <PACKAGE_DIRECTORY>

Восстановление пакетов для всего решения

SolutionDir> dotnet restore --packages <PACKAGES_DIRECTORY>

PowerShell PackageManagement

The commands listed here are specific to the Package Manager Console in Visual Studio, and differ from the Package Management module commands that are available in a general PowerShell environment.

И не видим ничего. А делать надо так:

Ага, есть такой пакет, называется Extended.Wpf.Toolkit. Теперь я его устанавливаю:

Естественно, никакие ссылки в проект не добавляются (т. е. в этом смысле PowerShell PackageManagement работает аналогично nuget.exe).
А теперь я хочу посмотреть список установленных пакетов:

Get - Package -Destination SolutionDir\packages
Name Version Source ProviderName
---- ------- ------ ------------
Extended.Wpf.Toolkit 3.5.0 SolutionDir\Extended.Wpf.Toolkit. NuGet

Переход с Nuget на Paket

При безусловных преимуществах, которые дает использование Nuget, есть и некоторые мелкие неудобства. Нас с коллегами например напрягало, что при установке (или восстановлении) пакета средствами Visual Studio в проект всегда добавляются ссылки на сборки пакета с установленным свойством Copy Local = True, т. е. они будут копироваться в выходную папку проекта, а нас такое поведение не устраивало по некоторым причинам.

1. Вам придется создать в корне вашего решения папку .paket, а поскольку имя папки начинается с точки, вы сможете сделать это только из командной строки:

2. Есть еще одна инструкция по установке, которая говорит: скачав файл paket.bootstrapper.exe в папку .paket, переименуйте его в paket.exe и закоммитьте (игнорировать его при помощи файла .gitignore, не надо). Зачем все это надо, написано в описании файла paket.bootstrapper.exe.

3. Для удобства пользования утилитой packet.exe существует расширение для Visual Studio под названием Paket for Visual Studio, которое обеспечивает некие плюшки, в частности подсветку синтаксиса и InteliSense для файлов paket.dependencies и paket.references. Но это расширение не устанавливается для Visual Studio 2019.

Установив paket.exe, подготавливаем наше решение (имеется в виду Visual Studio solution). Создаем в папке решения файл paket.dependencies. В нем перечисляются все пакеты для всех проектов решения, обычно, с указанием версий. Для одного из моих решений файл выглядит так:

// paket.dependencies file for paket package manager utility

// restrict target framework
framework: >= net46

// don't copy referenced assemblies to project's output directory
copy_local: false

// NuGet packages
nuget Accord 3.8.0
nuget Accord.Imaging 3.8.0
nuget Accord.MachineLearning 3.8.0
nuget Accord.Math 3.8.0
nuget Accord.Statistics 3.8.0
nuget Accord.Video 3.8.0
nuget Accord.Vision 3.8.0
nuget AForge 2.2.5
nuget AForge.Imaging 2.2.5
nuget AForge.Math 2.2.5
nuget AForge.Video 2.2.5
nuget AForge.Video.DirectShow 2.2.5
nuget AvalonEdit 5.0.4
nuget Extended.Wpf.Toolkit 2.5
nuget Mantin.Controls.Wpf.Notification 3.2.0.0
nuget MessagingToolkit.QRCode 1.3.0
nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform 2.0.1
nuget Ookii.Dialogs.Wpf 1.0.0
nuget System.ValueTuple 4.5.0
nuget System.Windows.Interactivity.WPF 2.0.20525

После того как файл paket.dependencies создан, можно попросить paket закачать пакеты:

Команда paket.exe install генерирует в папке решения файл paket.lock, который описывает какой пакет от какого пакета зависит. У меня он выглядит так:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform
System.ValueTuple

Если теперь запустить paket.exe install, то нужные пакеты не только загрузятся в папку packages (если они уже не загружены), но и в файл проекта (.csproj) добавятся ссылки на сборки из этих пакетов. Я уже писал выше, что для меня было важно в ссылках на сборки контролировать параметр Copy Local и делать его равным False. В paket это достигается строчкой copy_local: false в файле paket.dependencies.

Вот собственно и весь процесс использования paket. Последнее, что нужно сказать: если вы в своем решении уже пользовались NuGet, и переходите на paket, то утилита paket может выполнить этот переход полностью автоматически (т. е. вам не придется делать все, что было описано выше, нужно будет только скачать paket.exe):

Создание проектов и решений без Visual Studio

Создание файлов проектов и решений вручную

<Target Name = "PostBuild" AfterTargets = "Build" >

<Exec Command = "echo POSTBUILD COPYING OUTPUT FILES" />

<Copy SourceFiles = "@(OutputFiles)"
DestinationFolder = "$(DistributionFolder)" />
</Target >
</Project >

Во фрагменте файла проекта (.csproj) даны комментарии по терминологии (в MSBuild ключевую роль играют понятия: Target, Task, Property и Item). По принципам своей работы MSBuild очень похожа на утилиту make.

Небольшое отступление. Если речь не идет о создании нового файла проекта (.csproj), а лишь об изменении имеющегося, то даже необязательно редактировать файл проекта. Те изменения, которые вы планируете внести в файл проекта можно вынести в отдельные два файла Directory.Build.props и Directory.Build.targets, которые утилита MSBuild сама ищет в папке проекта и выше нее и импортирует в проект. Подробнее об этом читайте в статье Customize your build.

Утилита dotnet.exe

dotnet new sln -n MySolution
dotnet new classlib -n MyProject
dotnet sln MySolution.sln add MyProject/MyProject.csproj
dotnet build

Утилита CMake

Программная генерация файлов проектов и решений

Резюме

Сборка решения

MSBuild

SolutionDir> MSBuild.exe -property:Configuration=Release

Чтобы программа MSBuild успешно запустилась из командной строки, вам нужно либо добавить путь к папке, где лежит msbuild.exe в переменную окружения PATH (у меня это C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin ), либо запускать командную строку Visual Studio Command Prompt либо указывать полный путь к файлу MSBuild.exe.

Build Systems (автоматизация сборки решения)

Очистка решения и ⁄ или дистрибутива
Установка ⁄ восстановление ⁄ обновление пакетов
Построение проектов
Формирование дистрибутива (копирование всяких файлов в папку дистрибутива)

В итоге остановились на системе Nuke.

Установка Nuke на компьютер:

Установка Nuke в решение Visual Studio:

Далее у меня состоялся с утилитой следующий диалог:

How should the build project be named?
┐ nuke_build_project
Where should the build project be located?
┐ nuke_build_project
Which NUKE version should be used?
┐ 0.20.1 (latest release)
Which solution should be the default?
┐ MySuperBigSolution.sln
Do you need help getting started with a basic build?
┐ Yes, get me started!
Restore, compile, pack using .
┐ Neither
Source files are located in .
┐ ./src
Move packages to .
┐ Neither
Where do test projects go?
┐ ./tests
Do you use GitVersion?
┐ Yes, just not setup yet
Creating directory 'SolutionDir\nuke_build_project'.
Creating directory 'SolutionDir\tests'.

Пример очень простого кода Build.cs:

AbsolutePath SourceDirectory => RootDirectory / "src" ;

Итак, у нас есть проект программы, которая выполняет сборку решения. Теперь чтобы запустить процесс сборки решения, надо выполнить в командной строке powershell скрипт build.ps1:

SolutionDir> .\build.ps1 -target compile -configuration release

Расширения для Visual Studio

Command Task Runner

Вот пример файла commands.json с двумя задачами (BuildRelease и Clean), которые выполняются путем запуска скрипта build.ps1 (скрипт PowerShell, который появился при установке Nuke):

NUKE Support

Как пользоваться VS Code

Command Palette

Отладка в VS Code

В VS Code почему-то можно отлаживать только 64-разрядные программы, поэтому вам придется специально построить 64-разрядную версию своей программы. Для этого при компиляции вы должны передать утилите MSBuild параметр командной строки /p:Prefer32Bit=False . Если мы запускаем MSBuild из проекта nuke, то можно добавить такую tagret в исходный код проекта nuke:

Благодарности

Есть ли способ установить версию 15.3 из MSBuild на сервер сборки без установки Visual Studio 2017?

Нам нужна версия 15.3 для создания проекта Azure функций.

4 ответа

Синтаксис if constexpr , введенный с C++17, должен работать с переключателем компилятора /std:c++14 , согласно этой документации: C++17 функции в Visual Studio 2017 версии 15.3 Preview . Однако это не работает. Вместо этого генерируется следующая ошибка компилятора: ошибка C4984: 'if.

Мне нужно MSBUILD 14.0 и я готов установить Visual Studio, чтобы получить его. Какую версию Visual Studio мне нужно установить, чтобы получить MSBUILD 14.0? Похоже, что номер версии MSBUILD и имя Visual Studio не совпадают.

Ответ на этот вопрос может помочь вам

vs_buildtools__1882505178.1548260078.exe --макет c:\VS_BuildTools --добавить Microsoft.VisualStudio.Workload.MSBuildTools --добавить Microsoft.VisualStudio.Workload.VCTools --lang en-US --includingOptional

"vs_buildtools__1882505178.1548260078.exe" следует заменить версией, которую вы загрузили на сайт.
путь "c:\VS_BuildTools", где должен находиться установщик.