Dev Containers for C++ in Visual Studio

Marc Goodner

September 14th, 20222 5

We are happy to share with you that we have added Dev Container support In Visual Studio 2022 17.4 for C++ projects using CMake Presets.

Containers are a great way to package up everything for running an application. Through a Dockerfile all prerequisites are captured so that there is a consistent runtime environment anywhere the container is deployed and run Dev Containers expand this concept to capture everything necessary for developing and building an application in the container. We have been observing for some time that containers are becoming more popular in the C++ community for providing reproducible build environments.

Visual Studio Code has had support for Dev Containers for some time now. Beginning in Visual Studio 2022 17.4 you can now use Dev Containers for your C++ projects as well.

Trying Dev Container support

You will need to have Docker Desktop installed on Windows to use this capability. This is part of the Linux and embedded development with C++ workload., so make sure that is selected in your installation.

We have enabled this capability for projects that use CMake Presets. You can clone this sample to get started.

git clone git@github.com:robotdad/visualstudio-devcontainer-cpp.git

This project is the same as File New CMake Project in Visual Studio with one difference. There is an additional folder .devcontainer that contains the Dockerfile and devcontainer.json which together define the Dev Container to start.

On opening this folder in Visual Studio you will be prompted to reopen the folder in a container.

On first use when the container is started the backing image is downloaded. You can see progress of the startup in the new Dev Containers output window.

When startup is finished CMake cache generation starts, when it is done you can edit and debug as normal.

You can switch between your Dev Container and other options using the Target System drop down in the tool bar.

Options

Dev Containers have a few options under Tools Options. Most importantly you can control whether or not you want to be prompted to reopen in a container. You can also set a remote host to be the location to run containers, the remote host must be running docker services.

Notes

The feature uses Linux containers. We are not supporting Windows containers with this mechanism, as such this is not relevant for traditional Windows C++ development using MSVC. The is intended for cross platform development.

A backend service for Visual Studio Code runs within a Dev Container, this is not the case for Visual Studio. Visual Studio manages the lifecycle of Dev Containers it uses as you work, but it treats them as remote targets in a similar way to other Linux or WSL targets. The devcontainer.json configuration file may contain some VS Code specific information, like needed extensions, which are not relevant to Visual Studio. Those are ignored by Visual Studio so it is expected that there will be common Dev Container definitions used with either environment.

Do not open the same folder in Visual Studio and VS Code at the same time. This will result in them connecting to the same container which will result in conflicts between CMake running in two contexts against the same folder.

Send us your feedback

We hope that these new capabilities will enable you to choose Visual Studio for your C++ development needs and make you more productive. We are very interested in your feedback to continue to improve this experience. The comments below are open, or you can find us on Twitter (@VisualC), or via email at visualcpp@microsoft.com.

Marc Goodner Program Manager, C++

2 comments

Olivia September 21, 2022 9:45 pm 3

Good to see that this will finally come to Visual Studio.
When I try to open https://github.com/robotdad/visualstudio-devcontainer-cpp.git in the dev container on a remote Linux machine I get errors related to npm

> npx --no-install @microsoft/vscode-dev-containers-cli --version
Dev Containers CLI is not installed.
> npm install --no-audit node-pty-0.10.1.tgz
npm WARN tarball tarball data for file:node-pty-0.10.1.tgz (null) seems to be corrupted. Trying again.

The Linux machine is selected as the Host machine used to run containers. npm is installed. I use the same Linux machine for vscode development (ssh / containers) without issues.

When I “open” the folder in a dev container will it still use rsync to synchronize the source code?

I have already used vscode with dev containers in the past. This is ok for smaller projects with a single target. I also have to work with projects that can be developed in different containers for different platforms or toolchains. This becomes cumbersome with vscode. From that perspective I have found the Visual Studio approach more flexible. You can simply open a project once and just change the target system. The only limitation so far was that the target system has to be a WSL distro or must be reachable via ssh. Containers were not directly supported. As a workaround I can start multiple containers on the same “remote” Linux host and they are reachable through ssh. Then I can add the containers in the ConnectionManager and switch between them from Visual Studio. Since the containers are running on the same host and the same host path is mounted into the different containers to hold the source code, rsync becomes very efficient.

As far as I can see the new dev container support in Visual Studio 17.4 also means only one container per folder. In practice I can develop for Windows locally and for one other platform in a container. One idea would be that the ConnectionManager would somehow allow to add multiple devcontainer json files. Then we could have a list of devcontainers to select from in the target system like for WSL / ssh. When I select a devcontainer, vs would start the container on the host that is configured to run containers.

Marc Goodner September 28, 2022 3:56 pm 1

You have found a bug, running the container on a remote host is not currently working. We are tracking that, but if you can file an issue through Report a Problem in VS that would be helpful to us for tracking it as customer reported.

Yes, we are using rsync to synchronize the source code.

Regarding multiple decontainer.json files, that is not something we have considered.

Discussion is closed. Login to edit/delete existing comments.

Olivia September 21, 2022 9:45 pm 3
Good to see that this will finally come to Visual Studio.
When I try to open https://github.com/robotdad/visualstudio-devcontainer-cpp.git in the dev container on a remote Linux machine I get errors related to npm
```
> npx --no-install @microsoft/vscode-dev-containers-cli --version
Dev Containers CLI is not installed.
> npm install --no-audit node-pty-0.10.1.tgz
npm WARN tarball tarball data for file:node-pty-0.10.1.tgz (null) seems to be corrupted. Trying again.
```
The Linux machine is selected as the Host machine used to run containers. npm is installed. I use the same Linux machine for vscode development (ssh / containers) without issues.

When I “open” the folder in a dev container will it still use rsync to synchronize the source code?

I have already used vscode with dev containers in the past. This is ok for smaller projects with a single target. I also have to work with projects that can be developed in different containers for different platforms or toolchains. This becomes cumbersome with vscode. From that perspective I have found the Visual Studio approach more flexible. You can simply open a project once and just change the target system. The only limitation so far was that the target system has to be a WSL distro or must be reachable via ssh. Containers were not directly supported. As a workaround I can start multiple containers on the same “remote” Linux host and they are reachable through ssh. Then I can add the containers in the ConnectionManager and switch between them from Visual Studio. Since the containers are running on the same host and the same host path is mounted into the different containers to hold the source code, rsync becomes very efficient.

As far as I can see the new dev container support in Visual Studio 17.4 also means only one container per folder. In practice I can develop for Windows locally and for one other platform in a container. One idea would be that the ConnectionManager would somehow allow to add multiple devcontainer json files. Then we could have a list of devcontainers to select from in the target system like for WSL / ssh. When I select a devcontainer, vs would start the container on the host that is configured to run containers.
- Marc Goodner September 28, 2022 3:56 pm 1
  
  You have found a bug, running the container on a remote host is not currently working. We are tracking that, but if you can file an issue through Report a Problem in VS that would be helpful to us for tracking it as customer reported.
  
  Yes, we are using rsync to synchronize the source code.
  
  Regarding multiple decontainer.json files, that is not something we have considered.