With Visual Studio 2019 you can build and debug C++ projects on a remote Linux system or the Windows Subsystem for Linux (WSL). You can get started with Linux development in Visual Studio using MSBuild-based Linux projects or our native support for CMake. CMake lets you use the same source code and build scripts to target multiple platforms and is our recommendation for anything cross-platform or with an eye to open-sourcing. This blog post covers recent improvements to our Linux support in Visual Studio, including:

• Support for Ninja on Linux. Ninja is a build system with a focus on speed. Ninja has been the default generator (underlying build system) for CMake configurations targeting Windows for some time, but in Visual Studio 2019 version 16.6 Preview 3 we added support for Ninja on Linux. Ninja is typically faster than Unix Makefiles and is now the default generator for new CMake configurations targeting a remote system or WSL.
• First-class support for gdbserver. Gdbserver is a program that allows you to remotely debug applications running on Linux. It is especially useful in embedded scenarios where your target system may not have the resources to run gdb. In Visual Studio 2019 version 16.7 Preview 1 we added a new debugger configuration to debug CMake projects with gdbserver on remote systems. This eliminates the need for manual configuration of launch.vs.json as described in our previous blog post: Debugging Linux CMake Projects with gdbserver.
• Improvements to the Connection Manager. The Connection Manager in Visual Studio allows you to manage and store secure SSH connections to remote systems. We hear your feedback, and in Visual Studio 2019 version 16.7 Preview 2 you can edit and set default remote connections in the Connection Manager. This will allow you to edit an existing connection (e.g. if the IP address of your target device changed) and set default remote connections to be consumed in CMakeSettings.json and launch.vs.json via ${defaultRemoteMachineName} in CMake projects.

More details on all these new features are listed below.

Improved build times with Ninja on Linux

Ninja is a build system with a focus on speed. In Visual Studio 2019 version 16.6 Preview 3 we added support for building CMake projects with Ninja on remote Linux systems and WSL.

Ninja is typically faster than Unix Makefiles and is now the default generator for new CMake configurations targeting a remote system or WSL. You can install ninja on Debian-based Linux systems with the following commands:

sudo apt-get update

sudo apt-get install ninja-build

We ran performance tests to compare Ninja and Unix Makefiles on two open-source CMake projects: bullet3 and LLVM. These tests show the time for a full rebuild from Visual Studio and were run against a local VM (Ubuntu).

In Visual Studio 2019 version 16.6 Preview 3 or later you can try building your project on Linux directly from Visual Studio with CMake and Ninja to leverage these performance improvements and cut down on build times.

First-class support for gdbserver in CMake projects

In Visual Studio 2019 version 16.6 Preview 2 we introduced a new debugging template to simplify remote debugging with gdb. In Visual Studio 2019 version 16.7 Preview 1 we expanded on this template to include first-class support for debugging with gdbserver.

Debug sessions for CMake projects are configured in launch.vs.json. More information on this file and instructions for adding new configurations can be found in our updated documentation. A configuration of type ‘cppgdb’ is used to debug remotely on a Linux system or WSL.

  {
      "type": "cppgdb",
      "name": "CMakeLists.txt",
      "project": "CMakeLists.txt",
      "projectTarget": "",
      "comment": "Learn how to configure remote debugging. See here for more info http://aka.ms/vslinuxdebug",
      "debuggerConfiguration": "gdbserver",
      "args": [],
      "env": {}
  }

Visual Studio uses the front-end of the Visual Studio debugger backed entirely by gdb or gdbserver to debug on a remote system or WSL. You can select either gdb or gdbserver debugging via the debuggerConfiguration key.

debuggerConfiguration: Indicates which set of debugging default values to use. In Visual Studio 2019 version 16.6, the only valid option is gdb. Visual Studio 2019 version 16.7 or later also supports gdbserver.

There are additional options allowed with the gdbserver configuration, including:

gdbPath: Defaults to ${debugInfo.vsInstalledGdb}. Full Windows path to the gdb used to debug. By default, points to the gdb installed with the Linux development with C/C++ workload.

gdbserverPath: Defaults to usr/bin/gdbserver. Full Unix path to the gdbserver used to debug.

Our first-class support for gdbserver starts the gdbserver process on the remote target, pipes the gdbserver stdout and stderr to the Output Window, and kills the gdbserver process on any failures or on stop. A full list of additional options can be found in our updated documentation.

Note that we recommend using gdb for normal remote debugging scenarios. Gdbserver can be used when the target system may not have the resources to run the full gdb (e.g. in embedded scenarios). In this case, it may be helpful to leverage the separation of build and deploy to build on a more powerful Linux system (or locally on WSL) and debug on your low powered device using gdbserver.

Edit and set default remote connections in the Connection Manager

Finally, in Visual Studio 2019 version 16.7 Preview 2 we added the ability to edit and set default remote connections in the Connection Manager. The Connection Manager in Visual Studio allows you to manage and store secure SHH connections to remote systems.

You can now edit established remote connections (e.g. if the IP address of your target device changed) without removing the original connection. This means that Visual Studio will not need to recopy the include directories for the compiler on the remote system that are automatically copied over to Windows to provide a native IntelliSense experience. You can learn more about IntelliSense for Linux projects in Visual Studio in our recent blog post.

You can also set default remote connections to be consumed with the macro ${defaultRemoteMachineName} in CMakeSettings.json and launch.vs.json in CMake projects. This will enable you to check these files into source control without any user or machine specific configuration details.

Give us your feedback

Download Visual Studio 2019 version 16.7 Preview 2 today and give it a try. We’d love to hear from you to help us prioritize and build the right features for you. We can be reached via the comments below, Developer Community, and Twitter (@VisualC). The best way to file a bug or suggest a feature is via Developer Community.