Introduction
The security camera team had been evaluating Visual Studio as a unified development setup for their team’s C++ development, which includes remote Linux C++ development for cross-compiling.
While evaluating Visual Studio 2022, the team had a positive experience of using Visual Studio for their C++ development due to notable improvements over the years. Specifically, compared to their experience with Visual Studio 2019, they noticed improvements such as:
More seamless integration with GDB and a quicker debug experience within the inner-dev-loop
Better integration with CMake and WSL2 to allow for stabilized build environments and easily transferrable dev environments.
In Visual Studio 2022, they migrated their project from CMake settings to CMake presets to improve portability between Visual Studio and VS Code, compilation performance, and ease of maintaining multiple different configurations.
However, the Bosch team was still impacted by one issue with their Linux development which was that there was a gap in the current sync mechanism when switching between code branches. They had reached out to the Microsoft C++ team, who promptly resolved their issues in Visual Studio 2022 version 17.10. As a result of this collaboration, the workload has added new capabilities, which enable finer grain control of rsync settings when used with a remote rsync daemon. This is accomplished via a new CMake presets property for the user specification of rsync daemon parameters. The property supports explicit control over the copy. For example, the user can now explicitly turn on/off rsync’s symlink “munging” feature when copying.
“This step significantly decreased our issues during CMake configure and the average time needed for a configure-compiler-debug- cycle, not only because of the omitted additional step, but also there is less effort in doing syncing as well, as the copy keeps untouched. This overall increased our productivity and reduced the pain in cross-compiling for multiple targets.” – Bosch
This blog post was written in collaboration with Philipp Jeske and Rainer Bauereiss, a software engineer and a software engineering lead we worked with to deliver on these improvements, who shared their story and experience with C++ development while adopting Visual Studio 2022. Thank you both for your continued partnership over the years!
What does your team do? What technical challenges come from your work?
We are developing the OS and the applications for the Bosch security cameras. Involved is an international team with multiple locations which are contributing software modules for those cameras on multiple layers. Scaling this firmware to multiple types of cameras is key.
Our OS is based on Linux in different variants, that differ depending on the target. Each OS variant comes with its own SDK and toolchain for cross-compiling on a Linux host.
For embedded application development, we must work with different SDKs and toolchains. Most development is Windows based, but we also have Linux based machines. The toolchain is either locally installed or inside a WSL2 or other virtual machines tools. For limitations of some SDKs, the SDKs files are checked in as part of our application repository, and there come the symbolic links from our issue in play.
What was the process of re-evaluating and adopting Visual Studio as a unified IDE for the team like?
Some months ago, there wasn’t anything such as a unified development setup, but we were striving for a unified way of building our code.
We started a proof of concept using Visual Studio 2022 for cross-development on Windows Hosts, after previously evaluating Visual Studio 2019. We started with WSL2 integration and CMakeSettings.json. We noticed substantial improvements in how working with VS2022 looks and feels like after the substantial changes made in the year before.
During the evaluation phase of Visual Studio 2019 we had good contact with the C++ team, but sadly the tooling did not provide the functionality we needed. The main issue with Visual Studio 2019 before was the unsatisfying debug experience (due to lack of performance while compiling), when working remotely on a Linux-based system. The seamless integration from GDB into Visual Studio makes it nowadays one of the best debugging experiences we have encountered so far. The Visual Studio and Visual Studio Code remote development experience, especially for Linux and CMake-based projects, has clearly increased a lot since the last evaluation.
This setup already had some benefits by using Visual Studio as IDE and debugger interface, but it had its drawbacks, especially the lack of performance whilst compiling and the not-portable CMakeSettings.json configuration. Nevertheless, this setup has already convinced some of us and we have started out using this setup for our daily business.
In parallel, we experimented a bit and finally encountered that when we use CMake Presets, most of the drawbacks would be resolved. Therefore, we migrated from CMakeSettings.json to CMakePresets.json and with that setup our performance problem was gone, thanks to the rsync mechanism that removes the performance penalty that comes from compiling on a network share. Another advantage was that the configuration made in CMakePresets is compatible between Visual Studio and VS Code. Additionally, it makes it easier for us to maintain multiple different build configurations.
After migrating to CMake presets, what were your challenges with using Visual Studio?
We were so positive about the overall experience of using Visual Studio. However, there was a flaw present in the rsync mechanism preventing us from increasing the acceptance of the VS2022 solution widely across the team. Symlinks were getting munged when using rsync for cross-compiling our WSL targets. Because this was an issue for us and severity increased with the number of developers working with the new tool, we reached out to the Visual Studio C++ team with the hope of getting some additional information.
What is your current experience with Visual Studio now that the fix has been implemented?
Since the fix for our rsync issue is available in the preview for the upcoming release, most of us switched to the prerelease version. This step significantly decreased our issues during CMake configure and the average time needed for a configure-compile-debug-cycle decreased, not only because of the omitted additional step,but also because there is less effort in doing the syncing as well, as the copy keeps the file names untouched. This overall increased our productivity and reduced the pain in cross-compiling for multiple targets.
We are on the verge of migrating to MSVC as a mandatory toolchain for all our development. The portability between Visual Studio and Visual Studio Code makes both in our case a good tooling, because of our diverse environment. Furthermore, it enables the developers to choose the development environment that works for them. This increases productivity and satisfaction across the team.
The experience working with the Microsoft C++ team was very pleasant and solution oriented. We hope that we were able to share our appreciation for the tooling with the team that develops it.
You can adjust the value of munging symlinks via new rsync settings in the vendor block remote settings in CMake presets, as of Visual Studio 2022 version 17.10:
“rsyncCommandArgs”: [“-t”, “–delete”, “–no-munge-links”]
“rsyncDaemonOptions”: [“read only = no”, “list = True”, “munge symlinks = no”]
For example:
“configurePresets”: [
{
“name”: “windows-base”,
…
“vendor”: {
“microsoft.com/VisualStudioRemoteSettings/CMake/1.0”: {
“rsyncCommandArgs”: [“–no-munge-links”],
“rsyncDaemonOptions”: [“list = True”]
}
}
]
Conclusion
Bosch has successfully adopted Visual Studio 2022 as a unified IDE for their C++ Linux cross-compilation projects, thanks to migrating to CMake presets, overall improvements to the Linux experience in Visual Studio over the years and collaborating with the Microsoft C++ team to improve rsync mechanism issues.
Any developer targeting Linux with their CMake projects can try out the updates to the remote Linux experience with Visual Studio, including improvements to the CMake presets support and added rsync settings.
The Microsoft C++ team is continuously looking to improve the remote Linux experience with the IDE and would love to hear from any enterprises that work with Visual Studio. Please reach out to us via email at visualcpp@microsoft.com.