Как создать sln в visual studio code

Обновлено: 23.01.2025

Для тестирования нашего C/C++ анализатора PVS-Studio мы часто проверяем различные проекты с открытым исходным кодом и публикуем отчёты о найденных в них ошибках. И, конечно, очевидно, что для этого нам интересны проекты с большими объёмами исходного кода (сотни тысяч строк), ведь в нескольких десятках файлов ничего особенно не потестировать. Уже несколько раз нам попадались большие наборы, состоящие из сотен небольших открытых проектов. Примером таких коллекций проектов могут служить, например, наборы тестовых примеров для различных SDK и Framework'ов. Нам такие коллекции проектов особенно интересно проверять для тестирования поддержки анализатором различных специфичных конструкций кода, подтипов Visual C++ проектов и т.п.

Но у такого типа проектов существует не очевидный на первый взгляд недостаток — отсутствие единого проектного файла – решения. Зачастую, каждый проект в таких наборах независим и имеет совой solution. Понятно, что проверка 4-5 сотен sln файлов — не самое увлекательное занятие, причём работать с полученными таким путём сотнями отчётов будет весьма затруднительно.

Логика подсказывает, что для всех проектных файлов можно создать и один независимый sln файл — One Solution to Rule Them All, объединяющий все требуемые проекты. Но оказалось, что такая простая задача является нетривиальной для Visual Studio, ведь диалог добавления проекта позволяет выбирать только один проект за раз! Так что, даже если вам очень повезёт, и все проекты будут лежать в одной директории, процесс их добавления всё равно окажется мучительным.

И тут же поверхностный поиск показал, что не мы одни столкнулись с подобной проблемой. Но что обычно предлагают в таком случае? Сгенерировать "вручную" новый solution, и, открыв его как текстовый файл, добавить необходимые строки для каждого проекта. Что же скрывает за собой подобный метод? Ведь помимо необходимости вычитывать из каждого проекта его идентификаторы и конфигурации, не дай бог возникнет конфликт между зависимостями или теми же GUID'ами у хотя бы 2-х проектов. Ведь тогда придётся вручную обходить весь такой solution, чтобы определить проблему! В итоге же писать такую программу, которая должна будет всё это учитывать, но скорее всего, понадобится лишь пару раз, становится весьма обременительно.

Но ведь вся эта функциональность уже присутствует в самой Visual Studio — этот как раз тот самый Add Existing Project. Если бы была только возможность автоматизировать вызов данной команды и получение списка требуемых файлов. Но такая возможность существует, приём она может быть описана всего 4 строками кода:

Мы видим, что объект типа EnvDTE80.DTE2 позволяет программное добавить в текущее решение проект по имени файла. А ведь это как раз то, чего мы хотим! Причём метод AddFromFile также позволяет контролировать и добавляемые проекты, возвращая ссылку на каждый из них. А обертка этого кода в try. catch блок позволит отсечь все возможные конфликты между отдельными проектами.

Что же такое EnvDTE80.DTE2 и как его получить? Объект DTE (development environment) — это верхний объект API расширения среды Visual Studio, позволяющего автоматизировать работу с IDE и даже расширять возможности. Получить доступ к DTE можно несколькими разными способами, причём как из стороннего внешнего процесса, так и создав плагин-расширение (extension package) или подключаемый модуль для среды Visual Studio. А на нашем сайте есть цикл статей, посвящённый основам разработки подобных модулей расширения, в котором вы можете найти простые инструкции по созданию такого модуля прямо сейчас!

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:

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

Как отрыть Angular проект без .sln?
Добрый день. Имеется проект у опубликованный на хостинге в таком виде Возможно ли как-то.

Не могу открыть проект С++
Есть готовые исходники задачи, все лежит в папке, могу открыть каждый файл по отдельности и.

Не могу открыть проект
Привет всем. У меня горе((( Работал пол года над проектом и вдруг не могу его открыть. Дело в том.

Нужен сам проект решения весь . Ну а если хотите его открыть, то можно в текстовом редакторе. Там полный проект с решениями, попробовал открыть через текстовый редактор, не могу разобраться что теперь с этим делать, вышло как то так:
ну предположим наверно там не полный проект. Чет не хватает. Попробуйте скачать снова. Может при скачивании сбой был ну или типа того. 99% это проблема в проекте а не решении.
- там где скриншот. Достаточно открыть панель "Solution Explorer" (Ctrl + Alt + L). И там наверняка будет сразу видно что один из проектов (он один конечно же ) находится в стадии (не загружен)
- проекты можно открывать не через солюшен. Напрямую сказать - File - Open - Project и выбрать csproj. Но ошибка скорее всего будет той же.
Ну и разбираться что за файл там такой лежит. Часто бывает что руками исправляют и тэг не закрыт.

А добавлю там еще файлик есть скрытый. Он тоже нужен.
А кличут его там .suo . В скрытой папки и путь к нему .vs \ WindowsApp1 \ v16 \ .suo вроде такой путь или похожий

Добавлено через 8 минут
Я так думаю. Открыли папку с проектом скопировали файлы и отправили. а скрытый файлик остался дома.

Этот файлик на самом деле не нужен. Он не критичен. Когда какие-то проблемы со студией возникают, то как раз советуют удалить всю папку ".vs" (с этим файлом разумеется). В нём хранятся пользовательские настройки для конкретно этого солюшена (Solution User Options (.Suo)).
Так что наоборот лучше стирать такие папки если берёшь у кого-то. Их даже в репозиториях не сохраняют.

Добавлено через 1 час 1 минуту
SodaV, А че там пишут в окне Вывод

SodaV, такое ощущение что у вас только SLN файл и есть. Что именно вам прислали на почту?

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Не могу открыть чужой проект
Проблема в том что свои проекты могу открыть указав рабочее пространство при входе , а чужие.

Не могу открыть проект NetBeans
Делаю проект майнкрафт, сейчас делаю лаунчер, все сделал, не запускается проект когда нажимаю.

Не могу открыть проект в STM32IDE
Не получается открыть проект создан в STM32IDE. При включении IDE я выбираю путь к / stm32f103c8t.

Не могу создать/открыть проект
При попытке создать или открыть уже готовый проект Visual Basic, компьютер просто перезагружается

Поскольку мне всё равно пришлось ставить Visual Studio Community для того, чтобы установить Windows Kits для работы с WinAPI, то я решил не использовать MingW, а доустановить C++ build tools и использовать их для компиляции. В этом случае придётся переделать задачи (tasks) и настройки VSCode.

Хорошее описание нашёл здесь, его и буду использовать в данной заметке.

Нам потребуется

1. Естественно нам потребуется сама программа VSCode.
2. В Visual Studio Community должен быть установлен компонент Desktop development with C++ :

Чтобы проверить успешную установку, достаточно вызвать Developer Command Prompt for VS 2019 (файл VsDevCmd.bat ) из Пуска. Там нужно запустить файл cl.exe . Вывод консоли должен быть без ошибок:

3. Для VSCode должно быть установлено дополнение (расширение) Microsoft C/C++

Настройка

4. В Проводнике открываем рабочую папку проекта и, удерживая Shift , нажимаем правую кнопку мыши, после чего выбираем Open PowerShell window here
5. В открывшемся окошке PowerShell запускаем VSCode, для этого нужно набрать code . и нажать Enter :

Шаги 9-11 скорее всего не нужны. В статье они есть, но без них у меня всё тоже прекрасно компилируется.

9. Открываем палитру команд с помощью комбинации клавиш Ctrl + Shift + P
10. Список большой, поэтому проще ввести часть слова и выбрать нужную команду Edit Configurations UI из списка:

11. В конфигурации необходимо проверить, а, при необходимости, установить путь для компилятора:

12. Внесём изменения в файл settings.json :

У меня глобальный файл настроек, а не только для проекта, поэтому я добавляю строчки в начало файла C:\Users\Denis\AppData\Roaming\Code\User\settings.json

13. Ранее я уже создавал файл Задач tasks.json, поэтому сейчас я добавлю к нему новые строчки:

14. Чтобы у нас была возможность запустить проект на отладку, можно использовать файл launch.json . Но я не хочу создавать такой файл для каждого проекта каждый раз, поэтому сделаю глобальную конфигурацию. Для этого я добавлю строчки в файл settings.json :

Благодаря этому, при нажатии F5 , проект будет откомпилирован, а потом запущен сразу после этого. Просто запустить, без отладки, можно комбинацией Ctrl + F5

Читайте также: