Visual studio удаленная отладка linux

Debug .NET Core on Linux using SSH by attaching to a process

Starting in Visual Studio 2017, you can attach to .NET Core processes running on a local or remote Linux deployment over SSH. This article describes how to set up debugging and how to debug. For debugging scenarios using Docker containers, see Attach to a process running on a Docker container and the container tools articles instead. To debug Linux on WSL 2 from Visual Studio (no attach to process), see Debug .NET Core Apps in WSL 2 with Visual Studio.

Prerequisites

On the Visual Studio computer, you need to install either the ASP.NET and web development workload or the .NET Core cross-platform development workload.

On the Linux server, you need to install SSH server, unzip and install with either curl or wget. For example, on Ubuntu you can do that by running:

SFTP must be enabled as well as SSH. Most SSH distributions install and enable SFTP by default, but that is not always the case.

On the Linux server, install the .NET runtime on Linux, and find the page matching your Linux distribution (such as Ubuntu). The .NET SDK is not required.

Prepare your application for debugging

To prepare your application for debugging:

Consider using a Debug configuration when you build the application. It is much harder to debug retail-compiled code (a Release configuration) than debug-compiled code. If you need to use a Release configuration, first disable Just My Code. To disable this setting, choose Tools > Options > Debugging, and then deselect Enable Just My Code.

Make sure your project is configured to produce portable PDBs (which is the default setting), and make sure the PDBs are in the same location as the DLL. To configure this in Visual Studio, right-click the project, then choose Properties > Build > Advanced > Debugging Information.

Build and deploy the application

You can use several methods to deploy the app prior to debugging. For example, you can:

Copy sources to the target computer and build with dotnet build on the Linux machine.

Build the app on Windows, and then transfer the build artifacts to the Linux machine. (The build artifacts consist of the application itself, the portable PDBs, any runtime libraries it might depend on, and the .deps.json file.)

When the app is deployed, start the application.

Attach the debugger

When the application is running on the Linux machine, you are ready to attach the debugger.

In Visual Studio, choose Debug > Attach to Process….

In the Connection Type list, select SSH.

Change the Connection Target to the IP address or host name of the target computer.

If you haven’t already provided credentials, you will be prompted to enter a password and/or private key file.

There are no port requirements to configure, except the port that the SSH server is running on.

Find the process that you would like to debug.

Your code runs either in a unique process name or a process named dotnet. To find the process that you’re interested in, check the Title column, which shows the command line arguments for the process.

In the following example, you see a list of processes from a remote Linux machine over an SSH transport displayed in the Attach to Process dialog box.

Choose Attach.

In the dialog that appears, select the type of code you would like to debug. Choose Managed (.NET Core for Unix).

Use Visual Studio debugging features to debug the app.

In the following example, you see the Visual Studio debugger stopped at a breakpoint in code running on a remote Linux machine.

Источник

Отладка приложений .NET в WSL с помощью Visual Studio

Вы можете легко запускать и отлаживать свои .NET-приложения в Linux, не выходя из Visual Studio, посредством использования WSL. Если вы разрабатываете кросс-платформенные приложения, этот метод предоставляет простой способ тестировать большинство целевых сред.

Для пользователей Windows .NET, разрабатывающих приложения для Linux, WSL 2 — это оптимальное сочетание реалистичной рабочей среды и высокой производительности. В Visual Studio вы уже можете выполнять отладку в удаленной среде Linux, используя удаленный отладчик или контейнеры с помощью соответствующих средств. Эти варианты подойдут, если больше всего необходимо достичь реалистичных условий. Когда более важен простой и быстрый внутренний цикл, WSL является отличным вариантом.

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

Начиная с Visual Studio 2019 версии 16.11 Preview 3, цель отладки WSL 2 была переименована в WSL.

Предварительные требования

Visual Studio 2019 v16.9 Preview 1 или более поздние версии с отладкой .NET с дополнительным компонентом WSL.

Чтобы проверить наличие компонента WSL, выберите Сервис > Получить средства и компоненты. В Visual Studio Installer убедитесь, что компонент установлен, выбрав вкладку Отдельные компоненты и введя WSL в поле поиска.

В некоторых версиях Visual Studio дополнительный компонент включен по умолчанию с некоторыми рабочими нагрузками .NET.

Установленный дистрибутив по вашему усмотрению.

Запуск отладки с WSL

После установки необходимых компонентов откройте веб-приложение ASP.NET Core или консольное приложение .NET Core в Visual Studio. Вы увидите новый профиль запуска с именем WSL:

Выберите этот профиль, чтобы добавить его в файл launchSettings.json.

В следующем примере показаны некоторые ключевые атрибуты в файле.

Начиная с Visual Studio 2022 Preview 3, имя команды в профиле запуска изменилось с WSL2 на WSL.

После выбора нового профиля расширение проверяет, настроен ли ваш дистрибутив WSL для запуска приложений .NET, и помогает вам установить любые недостающие зависимости. После того, как вы установили эти зависимости, вы готовы к отладке в WSL.

Запустите отладку привычным способом, и ваше приложение будет работать в вашем распространении WSL по умолчанию.

Простой способ убедиться, что вы используете Linux, — проверить значение Environment.OSVersion .

Протестированы и поддерживаются только Ubuntu и Debian. Другие дистрибутивы, поддерживаемые .NET, должны работать, но для этого требуется вручную установить среду выполнения .NET и cURL.

Выбор конкретного дистрибутива

По умолчанию профиль запуска WSL 2 использует стандартный дистрибутив, заданный в файле wsl.exe. Если нужно запустить профиль для другого конкретного дистрибутива, независимо от используемого по умолчанию, можно изменить профиль запуска. Например, если вы отлаживаете веб-приложение и хотите проверить его в Ubuntu 20.04, профиль запуска будет выглядеть следующим образом:

Ориентация на несколько дистрибутивов

Если вы создаете приложение, предназначенное выполняться в нескольких дистрибутивах, и хотите быстро проверить работу в каждом из них, следующим шагом будет создание нескольких профилей запуска. Например, если необходимо проверить консольное приложение в Debian, Ubuntu 18.04 и Ubuntu 20.04, можно использовать следующие профили запуска:

Эти профили запуска обеспечивают легкое и удобное переключение между целевыми дистрибутивами, при этом не нужно выходить из Visual Studio.

Параметры WSL в профиле запуска

В следующей таблице приведены параметры, которые поддерживаются в профиле запуска.

Имя	По умолчанию	Назначение	Поддержка маркеров
executablePath	dotnet	Путь к исполняемому файлу, который следует запустить.	Да
commandLineArgs	Значение свойства «TargetPath» MSBuild, сопоставленное со средой WSL.	Аргументы командной строки, переданные согласно параметру executablePath.	Да
WorkingDirectory	Для консольных приложений — <OutDir>. Для веб-приложений — <ProjectDir>.	Рабочий каталог, в котором следует запустить отладку.	Да
environmentVariables	Пары «ключ — значение» переменных среды, которые необходимо установить для отлаживаемого процесса.	Да
setupScriptPath	Скрипт, который следует запустить перед отладкой. Используется для выполнения таких скриптов, как /.bash_profile.	Да
distributionName	Имя дистрибутива WSL, который следует использовать.	Нет
launchBrowser	false	Указывает, следует ли запускать браузер.	Нет
launchUrl	URL-адрес, по которому следует перейти, если для параметра launchBrowser задано значение true.	Нет

<ProjectDir> — путь к каталогу проекта.

<OutDir> — значение свойства OutDir MSBuild.

Все пути указываются для WSL, а не для Windows.

Источник

Развертывание, запуск и отладка проекта MSBuild Linux

Поддержка Linux реализована в Visual Studio версии 2017 и выше. Чтобы увидеть документацию для этих версий, установите в расположенном над содержанием раскрывающемся списке Версия пункт Visual Studio 2017 или Visual Studio 2019.

После создания проекта Linux на основе MSBuild C++ в Visual Studio и подключения к проекту с помощью диспетчера подключений Linux можно запускать и отлаживать проект. Компиляция, выполнение и отладка кода осуществляются в удаленной системе.

Visual Studio 2019 версии 16.1 Вы можете использовать разные системы Linux для отладки и сборки. Например, при работе с Интернетом вещей можно выполнить компиляцию на платформе x64 и развернуть приложение на устройстве ARM. Дополнительные сведения см. в разделе Указание разных компьютеров для сборки и отладки далее в этой статье.

Существует несколько способов взаимодействия с проектом Linux и его отладки.

Использование традиционных средств Visual Studio, таких как точки останова, окна контрольных значений и наведение указателя мыши на переменную. С их помощью вы можете выполнять отладку так, как вы делаете это для других типов проектов.

Просмотрите выходные данные целевого компьютера в окне консоли Linux. Консоль можно также использовать для отправки входных данных на целевой компьютер.

Отладка проекта Linux

Выберите режим отладки на странице свойств Отладка.

GDB используется для отладки приложений на платформе Linux. При отладке в целевой системе (не WSL) GDB может работать в двух разных режимах, которые можно указать с помощью параметра Режим отладки на странице свойств Отладка проекта:

«Отладка», выбранным пунктом «Режим отладки» и выбранным параметром «gbd» в раскрывающемся списке.» data-linktype=»relative-path»>

GDB используется для отладки приложений на платформе Linux. GDB может работать в двух разных режимах, которые выбираются в параметре Режим отладки на странице свойств Отладка проекта:

«Отладка», выбранным пунктом «Режим отладки» и выбранным параметром «gbd» в раскрывающемся списке.» data-linktype=»relative-path»>

В режиме gdbserver GDB выполняется в локальной среде, подключенной к gdbserver в удаленной системе.

В режиме gdb в Visual Studio отладчик запускает GDB в удаленной системе. Это лучший вариант, если локальная версия GDB несовместима с версией, установленной на целевом компьютере. Это единственный режим, который поддерживает окно консоли Linux.

Если не удается попасть в точки останова в режиме отладки gdbserver, попробуйте gdb режим. gdb сначала следует установить в удаленной целевой системе.

Выберите удаленную целевую систему, используя стандартную панель инструментов Отладка в Visual Studio.

Если удаленная целевая система доступна, вы определите ее по имени или IP-адресу.

Если вы еще не подключились к удаленной целевой системе, вы увидите инструкции по использованию диспетчера подключений Linux для выполнения подключения.

Задайте точку останова, щелкнув в левом поле код, который будет выполняться.

В строке кода, где вы задали точку останова, появится красная точка.

Нажмите клавишу F5 (или Отладка > Начать отладку), чтобы начать отладку.

При запуске отладки приложение компилируется на удаленном целевом компьютере и после этого запускается. Ошибки компиляции будут показаны в окне Список ошибок.

Если ошибок нет, приложение запустится, и по достижении точки останова отладчик остановится.

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

Если для взаимодействия с приложением вы хотите использовать консоль Linux, выберите Отладка > Консоль Linux.

Эта консоль отображает выходные данные консоли с целевого компьютера, принимает входные данные и отправляет их на целевой компьютер.

Настройка других параметров отладки (проекты MSBuild)

Аргументы командной строки можно передать в исполняемый файл с помощью элемента Аргументы программы на странице свойств Отладка проекта.

Вы можете экспортировать переменную среды DISPLAY с помощью команды перед запуском на страницах свойств Отладка проекта. Пример: export DISPLAY=:0.0

Специальные параметры отладчика можно передать в GDB с помощью записи Дополнительные команды отладчика. Например, можно игнорировать сигналы SIGILL (недопустимая инструкция). Для этого вы можете применить команду handle, добавив следующий текст в поле Дополнительные команды отладчика, как показано выше:

handle SIGILL nostop noprint

Путь к файлу GDB, который используется Visual Studio, можно указать с помощью элемента GDB Path (Путь к GDB) на странице свойств Отладка проекта. Это свойство доступно в Visual Studio 2019 версии 16.9 и более поздних версий.

Отладка с использованием присоединения к процессу

Страница свойств Отладка для проектов Visual Studio и параметры Launch.vs.json для проектов CMake позволяют подключиться к выполняющемуся процессу. Если вам требуется расширенный контроль, можно поместить файл с именем Microsoft.MIEngine.Options.xml в корневой каталог решения или рабочей области. Вот простой пример:

AttachOptionsForConnection имеет значительную часть атрибутов, которые могут потребоваться. Приведенный выше пример показывает, как указать расположение для поиска дополнительных библиотек .so. Дочерний элемент ServerOptions позволяет вместо этого подключиться к удаленному процессу с использованием gdbserver. Для этого необходимо указать локальный клиент gdb (экземпляр, предоставляемый с Visual Studio 2017, показан выше) и локальную копию двоичного файла с символами. Элемент SetupCommands позволяет передавать команды непосредственно в gdb. Все эти параметры доступны в схеме LaunchOptions.xsd на сайте GitHub.

Указание разных компьютеров для сборки и отладки в проектах Linux на основе MSBuild

Начиная с Visual Studio 2019 версии 16.1, вы можете отделить удаленный компьютер сборки от удаленного компьютера отладки для любых проектов MSBuild и CMake, которые будут использоваться с удаленным компьютером Linux. Например, при работе с Интернетом вещей теперь можно выполнить компиляцию на платформе x64 и развернуть приложение на устройстве ARM.

По умолчанию удаленный компьютер отладки совпадает с удаленным компьютером сборки (настраивается в разделе Свойства конфигурации > Общие > Удаленный компьютер сборки). Чтобы назначить для отладки другой удаленный компьютер, щелкните правой кнопкой мыши проект в обозревателе решений и перейдите к разделу Свойства конфигурации > Общие > Удаленный компьютер отладки.

В раскрывающемся меню Удаленный компьютер отладки перечислены все созданные удаленные подключения. Чтобы добавить новое удаленное подключение, откройте раздел Средства > Параметры > Кроссплатформенные > Диспетчер подключений или выполните поиск по строке «диспетчер подключений» на панели быстрого запуска. Кроме того, новый удаленный каталог для развертывания можно указать на страницах свойств проекта (Свойства конфигурации > Общие > Каталог удаленного развертывания).

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

Свойство Содержимое указывает, будет ли файл развертываться на удаленном компьютере отладки. Вы можете отключить развертывание полностью, перейдя в раздел Страницы свойств > Configuration Manager и сняв флажок Развернуть для соответствующей конфигурации.

В некоторых случаях может потребоваться более точный контроль над развертыванием проекта. Например, если некоторые файлы для развертывания расположены за пределами решения или вы хотите настроить несколько удаленных каталогов для разных исходных файлов или каталогов. Для таких случаев добавьте следующий блок кода один или несколько раз в файл с расширением .vcxproj, заменив в них строку example.cpp именами реальных файлов:

Проекты CMake

Для проектов CMake, которые будут использоваться с удаленным компьютером Linux, можно указать новый удаленный компьютер отладки в файле launch.vs.json. По умолчанию значение remoteMachineName синхронизируется со свойством remoteMachineName из файла CMakeSettings.json, который обозначает удаленный компьютер сборки. Теперь эти свойства могут не совпадать, а значение remoteMachineName в файле launch.vs.json обозначает удаленный компьютер, который используется для развертывания и отладки.

IntelliSense предложит полный список всех установленных удаленных подключений. Чтобы добавить новое удаленное подключение, откройте раздел Средства > Параметры > Кроссплатформенные > Диспетчер подключений или выполните поиск по строке «диспетчер подключений» на панели быстрого запуска.

Источник