How to use vs2019 for Linux remote development

Usually, there are two options when we develop Linux programs:

Write programs directly on Linux and run them for testing and debugging
Remote development with tools on Windows or Mac OS X

Although I develop directly in the Linux environment, there are also many people who do development work in the Windows environment. If they leave the familiar system and go to an unfamiliar environment, it may affect their work efficiency.

So today we will take a look at how to use Visual Studio 2019 on Windows for Linux remote development and how to avoid common pitfalls.

Introduction to Visual Studio's cross-platform development features

Starting from Visual Studio 2017, Microsoft launched the cross-platform development function of VS. You can edit the code in VS, and then perform cross-platform compilation and remote debugging, which automates the work that we originally needed to do manually, greatly reducing our burden. The supported platforms include Android and Linux, which are the main features we will focus on today.

Maybe you are curious about how VS performs remote development. Although you can perform development without understanding this knowledge, I still hope to give a brief explanation in two minutes.

Remote development with vs is divided into two steps:

Create a connection to the remote environment, and then let VS synchronize the system header files in the remote environment to the local (you can also specify header files in other places, which will be explained later). C++ code completion only requires header files.
When the code is written, select the appropriate remote environment, vs will copy the target files and code to the specified location of the remote environment, and then compile it according to your configuration.
VS will then run your program in the gdb or gdbserver of the console, during which time you can fully enjoy the efficiency and convenience brought by the VS debugger.

After completing the above steps, you can debug your own cross-platform programs in VS.

Using vs2019 for Linux remote development

This is the end of the introduction. Let's take a look at the graphic tutorial for Linux development in vs2019. Before we begin, we need to do some preparation:

Install vs2019 and check the c++ for Linux function;
Prepare an available Linux remote environment, such as a Linux virtual machine with a static IP configured, and the GCC toolchain and openssh installed.

Now that we are ready, let's get down to business.

Create a project

After installing the c++ for Linux function, we will see the Linux option in the panel for creating a new project, as shown in the figure:

Here we chose to use the traditional vs project solution to build a blank console program. In subsequent articles, you can also see how to create a cmake project, which is not mentioned here for now.

There is nothing much to say below. Select the storage location of the project. Note that it is a local location. The location of the remote machine will be configured later:

Click Create and our remote development project is created successfully.

Configuring a Remote Project

VS cannot edit the configuration of an empty project, so we first create a main.cpp in the project, then click the top menu: Project->Properties, and you can see the project configuration interface:

The remote computer is added in the Remote Connection Manager during debugging. Normally, no changes are required here unless you need to change the project type or the location where the compiled results are stored. If there are multiple remote environments, you can also select them here.

The debugging part provides gdb and gdbserver . The former lets vs start a console on Linux, then runs gdb in it and returns the output. If your terminal on Linux is configured with color output, then unfortunately vs does not recognize them and will display them as original strings. When using gdbserver, gdbserver will be enabled remotely, and there will be no noise when the local vs parses the returned data. Here we choose gdbserver. If you find that you cannot set breakpoints, refer to Microsoft's suggestions and switch back to the gdb solution:

Next is the key point of configuration. First, configure the header files of the remote environment that need to be synchronized. With these files, VS can automatically complete and prompt your code:

The default copied path usually already contains most of the header files on Linux, and usually we don't need to make any changes. The synchronization of header files occurs after the first successful build of the project or manual synchronization after adding a remote connection.

Next is the choice of C/C++ compiler, that is, the configuration of gcc and g++ compilation parameters. Explaining these parameters is beyond the scope of our discussion. Here we only need to choose the appropriate C++ standard version:

Here we chose c++17. The other settings are the same as when developing on Windows. VS can automatically convert them into g++ parameters, so I will not go into details here.

Adding a remote environment

Only with a remote environment can we synchronize header files or perform debugging operations.

When you compile or debug your project for the first time, VS will automatically connect you to the remote environment. Of course, we recommend setting it up in Debug->Options->Cross-Platform->Connection Manager:

Fill in your remote IP/domain name. The default SSH port is 22. For security reasons, you need to change it to another port. The default configuration is used for demonstration purposes. The password is the same as above. You should consider using a more secure SSH private key to log in.

After the login is successful, the connection is added. We can see that there is also a setting item for the remote header manager under the manager, which is used to synchronize the header file:

Clicking the Update button will start synchronizing the header files, which will be cached locally. Since a large number of files need to be copied from the remote at one time, it may take a long time.

Now that the remote environment has been added, you can start writing code.

Local writing and remote debugging

Now you can write code for Linux in VS, and auto-completion works fine:

You can see that the header files and structures in Linux can be recognized. If you find that automatic completion is not possible (usually happens after adding a remote connection or changing the project settings), try closing vs and reopening it. If that doesn't work, try refreshing intellisense or resynchronizing the header files.

After editing, we can click the debug button to run our program:

Note that the built architecture must be consistent with the remote environment. For example, if the remote environment is x64, you can choose x64 or x86 here, but you cannot choose arm, otherwise an error will be reported.

This is the test code, which will output the version of the current Linux system kernel:

#include <sys/utsname.h>
#include <iostream>
#include <cstdio>

int main()
{
  auto start = chrono::high_resolution_clock::now();
  utsname names;
  if (uname(&names) != 0) {
    std::perror("cannot get unames");
  }

  std::cout << "Linux kernel version: " << names.release << std::endl;
}

Click Debug->Linux Console, and an interactive console will be displayed, where you can enter content or see the output of the program:

The program ran successfully.

Avoid pitfalls

After the remote compilation is successfully completed, we can then use the vs debugger to set breakpoints, view variables at breakpoints, and even perform dynamic performance analysis on the running Linux.

But before that, there are still some pitfalls that need to be avoided.

Chinese garbled characters

The trouble caused by encoding problems will always be put first. After all, when people see that the expected output is actually a bunch of garbled characters, they will inevitably get nervous.

As we all know, encoding issues have always been a difficult problem, especially when the Chinese environment on Windows is usually GB18030 or GBK, while on Linux it is unified as utf8.

Let's look at a practical example. Usually, if our program only contains ASCII characters, it is not easy to cause problems, so we add some Chinese characters:

#include <sys/utsname.h>
#include <iostream>
#include <cstdio>
#include <string>

int main()
{
  utsname names;
  if (uname(&names) != 0) {
    std::perror("cannot get unames");
  }

  std::cout << "Linux kernel version: " << names.release << std::endl;
  std::cout << "Input content: ";
  std::string input;
  std::cin >> input;
  std::cout << "You entered: " << input << std::endl;
}

For the test program above, we added some Chinese output information. Now open the console for debugging:

You can see that the Chinese output has become garbled. We enter some information and this is the result:

It can be seen that the Chinese characters written in the program are garbled, but our input is not. The reason is very simple. When inputting in the Linux console environment, the default encoding is utf8, so our input is encoded correctly, and the content in the source file is GB18030, so garbled characters will occur in the Linux console (which decodes and displays data in utf8 by default).

Knowing the cause of the error, the solution is very simple. Just change the encoding of the source file to utf8. We choose the simplest method and change the encoding in高級保存選項(this menu option is hidden by default, and there are many materials on the Internet that introduce how to display it):

After setting, save the file. Now the file encoding has been changed to utf8.

Now run the modified program:

The running results are also normal:

Using math functions and third-party libraries

Using the mathematical functions provided by the standard library on Linux is also a common problem. Depending on whether you use cpp or c, there will be the following situations:

When using cpp, libstdc++ depends on libm, so when you compile your program with g++, it will automatically link the math library;
When using C, if it is in the form of sqrt(4) , newer gcc provides a replacement measure, and there is no need to explicitly link libm;
Continuing from the previous point, if your argument is a variable, the compiler may choose to require you to link libm.

Normally we don't have to worry about this on Windows, but it's hard to ignore this problem when using C language on Linux.

So to be on the safe side, if you are writing a C program that uses mathematical functions, it is always a good idea to specify that you link against libm.

In addition, you also need to pay attention when you use third-party libraries such as boost. On Windows, we usually specify the additional include directory and additional library directory to compile normally, but on Linux, the name of the link library must be explicitly specified, so we set it in the project properties.

On Linux, we can use pkg-config to reduce the above repetitive work, but in vs we cannot directly use this tool. When your project uses a large number of third-party libraries, it will become a big trouble. If you want to solve this problem, you can refer to the vs+cmake build project that I will introduce in subsequent articles.

Next we add some boost chrono functional tests to the example. On Linux, we need to specify -lboost_chrono . Here is the setting:

Here is the complete code:

#include <sys/utsname.h>
#include <iostream>
#include <cstdio>
#include <string>
#include <boost/chrono.hpp>

int main()
{
  namespace chrono = boost::chrono;
  auto start = chrono::high_resolution_clock::now();
  utsname names;
  if (uname(&names) != 0) {
    std::perror("cannot get unames");
  }

  std::cout << "Linux kernel version: " << names.release << std::endl;
  std::cout << "Input content: ";
  std::string input;
  std::cin >> input;
  std::cout << "You entered: " << input << std::endl;
  auto counter = chrono::duration_cast<chrono::milliseconds>(chrono::high_resolution_clock::now() - start);
  std::cout << "The program ran: " << counter.count() << "ms\n";
}

Click the Run button and the program can be debugged normally, otherwise an error will be reported:

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.

You may also be interested in: