Over the past couple of months, the Microsoft C++ team reached out to a series of customers voting on a suggestion ticket asking for Remote Linux Unit Testing support to better understand their full set of interactions and needs with CMake and Remote Linux scenarios in Visual Studio. After these discussions, we built out a backlog of work items to deliver on any pain points in their experiences.

One of the customers we interviewed and worked closely with during the process was John Schultz, an Azure Networking software engineer. Our team helped John not only to be able to F5 run his CTest unit tests for Linux, improving his productivity on the scale of hours per run, but also improved his gdb debugger performance and overall IntelliSense issues with his configurations. These new improvements can be found in Visual Studio 17.9 Preview 2, so feel free to try out using the Test Explorer for your running and debugging your unit tests in remote Linux scenarios and notice the gdb debugger improvements on first breakpoint hit.

Below is an interview with John about his overall experience. Thank you, John, for working with us!

What does your team do?

I work on an Azure Networking team that designs, develops, and operates Azure platform services to support Virtual Networking and PrivateLink features. Our application is cross-platform and we use Visual Studio capabilities to develop for both Windows and Linux. For our application that runs on Linux, the target environment has very limited resources.

What was your development experience before working with the Visual C++ team?

Initially, we could not build in the IDE because we were using custom msbuild-targets for cross-compiling, which were slower and didn’t support IntelliSense. We had seen several posts online at the time that CMake was supported in both Visual Studio (VS) and VS Code, which drove us to ensure our CMake builds were properly functional.

After onboarding to CMakePresets.json and the Ninja generator, we got our CMake projects building in both VS and VS Code. This was awesome for the team as it enabled cross-platform compilation from the IDE integration. At this point, the next friction was running and debugging our unit tests.

Due to lack of remote Linux unit test support in the IDE, we attempted to attach to binaries running in our remote emulator, but the performance was much worse. Regardless, we would much prefer to stick with using Visual Studio for our remote Linux workflows because our team is familiar with Windows. The target system is built for a custom Linux image which is not designed for development, and VS has a suite of debugging and editing tools that we like to use such as IntelliSense, CMake Project System, GitMerge, CallStack, and Watches.

What was your development experience after working with the Visual C++ team?

The Visual C++ team first organized a call to understand our needs – which included adding remote Linux unit test support for CTests, improving upon gdb debugger performance issues, and getting IntelliSense configured for our remote scenarios.

The team then got to work on delivering on this set of asks and circling back with me to ensure that our experience was successful.

After some time, the C++ team notified us that the performance issues were addressed and helped us configure our launch.vs.json so that we could F5 our unit tests. The performance is much more acceptable and having this feature has already remarkably improved the developer experience in our team.

With this new ability to launch and debug using Visual Studio, we were able to onboard a new unit test in minutes, rather than hours (as has been the historic case using ssh, scp and gdb).

Conclusion

We hope these new improvements are able to empower remote Linux users from Visual Studio to increase their productivity with the IDE and have a seamless Linux targeting experience. Thank you so much John and the Azure Networking organization for your engagement and collaboration with the Visual Studio team.

Again, please try out Visual Studio 17.9 Preview 2’s new highly performant gdb debugger and remote Linux unit testing capabilities in the Test Explorer for CMake projects. Currently, the known limitations with remote Linux unit testing are with certain dev container scenarios which are targeted to be fixed by 17.9 Preview 3.

Some tips we would like to share from working with John to configure his remote scenarios are that:

• If you want to compile with IntelliSense in remote scenarios, you do not need extra information in your CMake Presets such as IntelliSenseOptions. It does not need any extra configuration steps and should automatically configure.
• If you are building on the same remote machine that you are debugging on then Visual Studio will copy binaries automatically to ~/.vs/<project-name/.
• If you are building on a different machine, then you can specify deployment options in the launch.vs.json like the example below:

     "deploy": [
        {
          "deploymentType": "LocalRemote",
          "executable": true,
          "sourceMachine": "localhost",
          "sourcePath": "C:\\path-to-exe",
          "targetMachine": "127.0.0.1",
          "targetPath": "/tmp/PortManagerTest"
        }
      ]

The Microsoft C++ team would love to hear from any enterprises that work with our IDE and would like to see improvements with their remote Linux and/or CMake scenarios. Please reach out to us via email at cmake@microsoft.com.