Visual studio linux console

Deploy, run, and debug your Linux MSBuild project

Linux support is available in Visual Studio 2017 and later. To see the documentation for these versions, set the Version drop-down located above the table of contents to Visual Studio 2017 or Visual Studio 2019.

Once you’ve created a MSBuild-based Linux C++ project in Visual Studio and you’ve connected to the project using the Linux Connection Manager, you can run and debug the project. You compile, execute, and debug the code on the remote target.

Visual Studio 2019 version 16.1 and later: You can target different Linux systems for debugging and building. For example, you can cross-compile on x64 and deploy to an ARM device when targeting IoT scenarios. For more information, see Specify different machines for building and debugging later in this article.

There are several ways to interact with and debug your Linux project.

Debug using traditional Visual Studio features, such as breakpoints, watch windows, and hovering over a variable. Using these methods, you may debug as you normally would for other project types.

View output from the target computer in the Linux Console window. You can also use the console to send input to the target computer.

Debug your Linux project

Select debugging mode in the Debugging property page.

GDB is used to debug applications running on Linux. When debugging on a remote system (not WSL) GDB can run in two different modes, which can be selected from the Debugging Mode option in the project’s Debugging property page:

Debugging selected and Debugging Mode highlighted with G D B selected and highlighted from the dropdown list.» data-linktype=»relative-path»>

GDB is used to debug applications running on Linux. GDB can run in two different modes, which can be selected from the Debugging Mode option in the project’s Debugging property page:

Debugging selected and Debugging Mode highlighted with G D B selected and highlighted from the dropdown list.» data-linktype=»relative-path»>

In gdbserver mode, GDB is run locally, which connects to gdbserver on the remote system.

In gdb mode, the Visual Studio debugger drives GDB on the remote system. This is a better option if the local version of GDB isn’t compatible with the version installed on the target computer. This is the only mode that the Linux Console window supports.

If you are unable to hit breakpoints in gdbserver debugging mode, try gdb mode. gdb must first be installed on the remote target.

Select the remote target using the standard Debug toolbar in Visual Studio.

When the remote target is available, you’ll see it listed by either name or IP address.

If you haven’t connected to the remote target yet, you’ll see an instruction to use Linux Connection Manager to connect to the remote target.

Set a breakpoint by clicking in the left gutter of some code that you know will execute.

A red dot appears on the line of code where you set the breakpoint.

Читайте также:  Как подключить сетевой принтер на макбуке

Press F5 (or Debug > Start Debugging) to start debugging.

When you start debugging, the application is compiled on the remote target before it starts. Any compilation errors will appear in the Error List window.

If there are no errors, the app will start and the debugger will pause at the breakpoint.

Now, you can interact with the application in its current state, view variables, and step through code by pressing command keys such as F10 or F11.

If you want to use the Linux Console to interact with your app, select Debug > Linux Console.

This console will display any console output from the target computer and take input and send it to the target computer.

Configure other debugging options (MSBuild projects)

Command-line arguments can be passed to the executable using the Program Arguments item in the project’s Debugging property page.

You can export the DISPLAY environment variable by using the Pre-Launch Command in the project’s Debugging property pages. For example: export DISPLAY=:0.0

Specific debugger options can be passed to GDB using the Additional Debugger Commands entry. For example, you might want to ignore SIGILL (illegal instruction) signals. You could use the handle command to achieve this by adding the following to the Additional Debugger Commands entry as shown above:

handle SIGILL nostop noprint

You can specify the path to the GDB used by Visual Studio using the GDB Path item in the project’s Debugging property page. This property is available in Visual Studio 2019 version 16.9 and later.

Debug with Attach to Process

The Debugging property page for Visual Studio projects, and the Launch.vs.json settings for CMake projects, have settings that enable you to attach to a running process. If you require more control beyond what is provided in those settings, you can place a file named Microsoft.MIEngine.Options.xml in the root of your solution or workspace. Here is a simple example:

The AttachOptionsForConnection has most of the attributes you might need. The example above shows how to specify a location to search for more .so libraries. The child element ServerOptions enables attaching to the remote process with gdbserver instead. To do that, you need to specify a local gdb client (the one shipped in Visual Studio 2017 is shown above) and a local copy of the binary with symbols. The SetupCommands element enables you to pass commands directly to gdb. You can find all the options available in the LaunchOptions.xsd schema on GitHub.

Specify different machines for building and debugging in MSBuild-based Linux projects

You can separate your remote build machine from your remote debug machine for both MSBuild-based Linux projects and CMake projects that target a remote Linux machine. For example, you can now cross-compile on x64 and deploy to an ARM device when targeting IoT scenarios.

By default, the remote debug machine is the same as the remote build machine (Configuration Properties > General > Remote Build Machine). To specify a new remote debug machine, right-click on the project in Solution Explorer and go to Configuration Properties > Debugging > Remote Debug Machine.

The drop-down menu for Remote Debug Machine is populated with all established remote connections. To add a new remote connection, navigate to Tools > Options > Cross Platform > Connection Manager or search for «Connection Manager» in Quick Launch. You can also specify a new remote deploy directory in the project’s Property Pages (Configuration Properties > General > Remote Deploy Directory).

Читайте также:  Как закачать картридж для принтера

By default, only the files necessary for the process to debug will be deployed to the remote debug machine. You can use Solution Explorer to configure which source files will be deployed to the remote debug machine. When you click on a source file, you’ll see a preview of its File Properties directly below the Solution Explorer.

The Content property specifies whether the file will be deployed to the remote debug machine. You can disable deployment entirely by navigating to Property Pages > Configuration Manager and unchecking Deploy for the desired configuration.

In some cases, you may require more control over your project’s deployment. For example, some files that you want to deploy might be outside of your solution or you want to customize your remote deploy directory per file or directory. In these cases, append the following code block(s) to your .vcxproj file and replace «example.cpp» with the actual file names:

CMake projects

For CMake projects that target a remote Linux machine, you can specify a new remote debug machine in launch.vs.json. By default, the value of «remoteMachineName» is synchronized with the «remoteMachineName» property in CMakeSettings.json, which corresponds to your remote build machine. These properties no longer need to match, and the value of «remoteMachineName» in launch.vs.json will dictate which remote machine is used for deploy and debug.

IntelliSense will suggest all a list of all established remote connections. You can add a new remote connection by navigating to Tools > Options > Cross Platform > Connection Manager or searching for «Connection Manager» in Quick Launch.


С/С++ на Linux в Visual Studio Code для начинающих

Давайте начистоту, мало кто использует отладчик GDB на Linux в консольном варианте. Но что, если добавить в него красивый интерфейс? Под катом вы найдёте пошаговую инструкцию отладки кода С/С++ на Linux в Visual Studio Code.

Передаю слово автору.

Относительно недавно я переехал на Linux. Разрабатывать на Windows, конечно, удобнее и приятнее, но и здесь я нашел эффективный способ легко и быстро отлаживать код на С/С++, не прибегая к таким методам как «printf-стайл отладки» и так далее.

Итак приступим. Писать в sublime (или gedit/kate/emacs ), а запускать в терминале — так себе решение, ошибку при работе с динамическим распределением памяти вряд ли найдёшь с первого раза. А если проект трудоёмкий? У меня есть более удобное решение. Да и ещё поддержка Git в редакторе, одни плюсы.

Сегодня мы поговорим про Visual Studio Code.


  1. Качаем версию пакета VS Code с расширением .deb
  2. Переходим в папку, куда скачался пакет (cd

/Загрузки или cd

Пишем, где (имя пакета).deb — название файла, который вы только что скачали:

OpenSUSE/SLE Based distrs

Обновим пакеты и установим VS Code:

Расширения для С/С++

Чтобы VS Code полностью сопровождал нас при работе с файлами С/С++, нужно установить расширение «cpptools». Также полезным будет поставить один из наборов сниппетов.

Настоятельно рекомендую включить автосохранение редактируемых файлов, это поможет нам в дальнейшем.

Идём дальше. Открываем любую папку (новую или нет, неважно).

У меня в этой папке уже есть пара файлов для работы с C/C++. Вы можете скопировать одну из своих наработок сюда или создать новый файл.

Осталось всего ничего. Настроить компиляцию в одну клавишу и научиться отлаживать без printf .

Шаг 1. Открываем файл .c/.cpp, который (обязательно) лежит в вашей папке.

Шаг 2. Нажимаем Ctrl+Shift+B. VS Code вам мягко намекнет, что он не знает как собирать ваш проект.

Шаг 3. Поэтому дальше настраиваем задачу сборки: выбираем «Настроить задачу сборки» -> «Others».

Шаг 4. Прописываем конфигурацию в соответствии с образцом. По сути мы пишем скрипт для консоли, так что всем кто имел дело с ней будет понятно дальнейшее. Прошу заметить, что для сборки исходников в системе должен стоять сам компилятор (gcc или другой, отличаться будет только значение поля command ). Поэтому для компиляции .cpp, понадобится в поле command указать g++ или c++ , а для .c gcc .

Шаг 5. В args прописываем аргументы, которые будут переданы на вход вашему компилятору. Напоминаю, что порядок должен быть примерно таким: -g, .

Внимание: Если в вашей программе используется несколько файлов с исходным кодом, то укажите их в разных аргументах через запятую. Также обязательным является ключ -g (а лучше даже -g3 ). Иначе вы не сможете отладить программу.

Если в проекте для сборки вы используете makefile , то в поле command введите make , а в качестве аргумента передайте директиву для сборки.

Шаг 6. Далее возвращаемся обратно к нашему исходнику. И нажимаем F5 и выбираем C++.

Шаг 7. Осталось только написать путь к файлу программы. По умолчанию это $/a.out , но я в своем файле сборки указал флаг -o и переименовал файл скомпилированной программы, поэтому у меня путь до программы: $/main .

Шаг 8. Всё, больше нам не нужно ничего для начала использования всех благ VS Code. Переходим к основному проекту.


Для начала скомпилируем программу (нет, нет, убери терминал, теперь это делается по нажатию Ctrl+Shift+B).

Как вы видите в проводнике появился main , значит все в порядке и сборка прошла без ошибок. У меня не слишком большая программа, но выполняется она моментально. Одним словом, провал чистой воды, потому что отладка идет в отдельном терминале, который закрывается после того, как программа дошла в main() до «return 0;» .

Пришло время для брейкпоинтов. Выберем строчку с «return 0;» и нажимаем F9.

Строчка, помеченная красной точкой слева — место, где остановится программа, при выполнении.

Далее нажимаем F5.

Как я и сказал, программа остановила выполнение. Обратите внимание на окно с локальными переменными.

Удобненько. Также при остановке можно наводить мышкой на переменные и структуры в коде и смотреть их значения.

Также, если на каком-то этапе выполнения вам нужно посмотреть пошаговое выполнение той или иной операции, например в цикле, то поставьте брейкпоинт перед ней и нажмите F10 для выполнения текущей строчки без захода в подпрограмму и F11 с заходом.

Также есть случаи, когда считать выражение очень муторно вручную, но для отладки вам нужно знать, например, значение суммы трех элементов массива, или значение большого логического выражения. Для этого существуют контрольные значения. Все это и многое другое могут показать вам Контрольные значения (или «watch»).

  1. Для каждой папки вам нужно отдельно настроить файлы сборки и путь к программе.
  2. VS Code не решит ваших проблем, но поможет быстрее с ними разобраться. Причем в разы.
  3. После каждого изменения программы, ее нужно компилировать заново, нажимая Ctrl+Shift+B.

Полезные шорткаты можно посмотреть здесь.


Поделиться с друзьями