# data[].attributes.attachment_link.description
Welcome to BrainImageNet: an Industrial-Grade Brain Imaging Based Deep Learning Classifier. We openly shared our code/framework, trained model (within the below docker hub file, due to the filesize is too large for github), and built an online predicting website for whoever are interested in testing our classifier to predict sex and AD status with brain imaging data from anybody and any scanner.

# data[].attributes.attachment_link.title
GitHub - BBillot/SynthSeg: Contrast-agnostic segmentation of MRI scans

# data[].attributes.attachment_link.description
In this repository, we present SynthSeg, the first convolutional neural network for segmentation of brain scans of any contrast and resolution that works out-of-the-box, without retraining or fine-tuning. SynthSeg relies on a single model, which is robust to: a wide array of subject populations: from young and healthy to ageing and diseased subjects, white matter lesions, scans with or without preprocessing, including bias field corruption, skull stripping, intensity normalisation, template registration, etc.

# data[].attributes.attachment_link.title
GitHub - MaciejMazurowski/brain-segmentation: Deep learning based skull stripping and FLAIR abnormality segmentation in brain MRI using U-Net

# data[].attributes.attachment_link.description
This is a source code for the deep learning segmentation used in the paper Association of genomic subtypes of lower-grade gliomas with shape features automatically extracted by a deep learning algorithm. It employs a U-Net like network for skull stripping and FLAIR abnormality segmentation.

# data[].attributes.attachment_link.title
GitHub - changken1/IDH_Prediction: Use of Deep Learning to Predict IDH status from MR Imaging

# data[].attributes.attachment_link.description
Use of Deep Learning to Predict IDH status from MR Imaging - GitHub - changken1/IDH_Prediction: Use of Deep Learning to Predict IDH status from MR Imaging

# data[].attributes.attachment_link.title
Git and GitHub for Beginners - Crash Course

# data[].attributes.attachment_link.title
Docker Tutorial for Beginners [FULL COURSE in 3 Hours]

# data[].attributes.attachment_link.title
TensorFlow 2.0 Complete Course - Python Neural Networks for Beginners Tutorial

# data[].attributes.attachment_link.title
Deep Learning With PyTorch - Full Course

# data[].attributes.attachment_link.readable_text
Visual Studio Code has integrated source control and includes Git support in-the-box. Many other source control providers are available through extensions on the VS Code Marketplace.

Tip: Click on an extension tile to read the description and reviews in the Marketplace.

SCM Providers

VS Code has support for handling multiple Source Control providers simultaneously. For example, you can open multiple Git repositories alongside your TFS local workspace and seamlessly work across your projects. The SOURCE CONTROL PROVIDERS list of the Source Control view (⌃⇧G (Windows, Linux Ctrl+Shift+G)) shows the detected providers and repositories and you can scope the display of your changes by selecting a specific provider.

SCM Provider extensions

If you would like to install an additional SCM provider, you can search on the scm providers extension category in the Extensions view (⇧⌘X (Windows, Linux Ctrl+Shift+X)). Start typing '@ca' and you will see suggestions for extension categories like debuggers and linters. Select @category:"scm providers" to see available SCM providers.

Git support

VS Code ships with a Git source control manager (SCM) extension. Most of the source control UI and work flows are common across other SCM extensions so reading about the Git support will help you understand how to use another provider.

Note: If you are new to Git, the git-scm website is a good place to start with a popular online book, Getting Started videos and cheat sheets. The VS Code documentation assumes you are already familiar with Git.

Note: VS Code will leverage your machine's Git installation, so you need to install Git first before you get these features. Make sure you install at least version 2.0.0.

Tip: VS Code will work with any Git repository. If you don't already have a private hosted Git provider, Azure DevOps Services is a great free option. Click here to sign-up.

The Source Control icon on the left will always indicate an overview of how many changes you currently have in your repository. Clicking it will show you the details of your current repository changes: CHANGES, STAGED CHANGES and MERGE CHANGES.

Clicking each item will show you in detail the textual changes within each file. Note that for unstaged changes, the editor on the right still lets you edit the file: feel free to use it!

You can also find indicators of the status of your repository in the bottom left corner of VS Code: the current branch, dirty indicators and the number of incoming and outgoing commits of the current branch. You can checkout any branch in your repository by clicking that status indicator and selecting the Git reference from the list.

Tip: You can open VS Code in a sub-directory of a Git repository. VS Code's Git services will still work as usual, showing all changes within the repository, but file changes outside of the scoped directory are shaded with a tool tip indicating they are located outside the current workspace.

Commit

Staging (git add) and unstaging (git reset) can be done via contextual actions in the files or by drag-and-drop.

You can type a commit message above the changes and press Ctrl+Enter (macOS: ⌘+Enter) to commit them. If there are any staged changes, only those will be committed, otherwise all changes will be committed.

We've found this to be a great workflow. For example, in the earlier screenshot, only the staged changes to gulpfile.js will be included in the commit. A consecutive commit action could commit later changes to gulpfile.js, the deletion of yarn.lock, and changes to tests.js in a separate commit.

More specific Commit actions can be found in the More Actions ... menu on the top of the Git view.

Cloning a repository

You can clone a Git repository with the Git: Clone command in the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)). You will be asked for the URL of the remote repository (for example on GitHub) and the parent directory under which to put the local repository.

For a GitHub repository, you would find the URL from the GitHub Clone or download dialog.

You would then paste that URL into the Git: Clone prompt.

You can create and checkout branches directly within VS code through the Git: Create Branch and Git: Checkout to commands in the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)).

If you run Git: Checkout to, you will see a drop-down list containing all of the branches or tags in the current repository.

The Git: Create Branch command lets you quickly create a new branch. Just provide the name of your new branch and VS Code will create the branch and switch to it.

Remotes

Given that your repository is connected to some remote and that your checked out branch has an upstream link to a branch in that remote, VS Code offers you useful actions to push, pull and sync that branch (the latter will run a pull command followed by a push command). You can find these actions in the More Actions ... menu.

VS Code is able to periodically fetch changes from your remotes. This enables VS Code to show how many changes your local repository is ahead or behind the remote. Starting with VS Code 1.19, this feature is disabled by default and you use the git.autofetch setting to enable it.

Tip: You should set up a credential helper to avoid getting asked for credentials every time VS Code talks to your Git remotes. If you don't do this, you may want to consider disabling automatic fetching via the git.autofetch setting to reduce the number of prompts you get.

Git Status Bar actions

There is a Synchronize Changes action in the Status Bar, next to the branch indicator, when the current checked out branch has an upstream branch configured. Synchronize Changes will pull remote changes down to your local repository and then push local commits to the upstream branch.

If there is no upstream branch configured and the Git repository has remotes set up, the Publish action is enabled. This will let you publish the current branch to a remote.

Gutter indicators

If you open a folder that is a Git repository and begin making changes, VS Code will add useful annotations to the gutter and to the overview ruler.

A red triangle indicates where lines have been deleted

A green bar indicates new added lines

A blue bar indicates modified lines

Merge conflicts

Merge conflicts are recognized by VS Code. Differences are highlighted and there are inline actions to accept either or both changes. Once the conflicts are resolved, stage the conflicting file so you can commit those changes.

Viewing diffs

Our Git tooling supports viewing of diffs within VS Code.

Tip: You can diff any two files by first right clicking on a file in the Explorer or OPEN EDITORS list and selecting Select for Compare and then right-click on the second file to compare with and select Compare with 'file_name_you_chose'. Alternatively from the keyboard hit ⇧⌘P (Windows, Linux Ctrl+Shift+P) and select File: Compare Active File With and you will be presented with a list of recent files.

Diff editor review pane

There is a review pane in the Diff editor which presents changes in a unified patch format. You can navigate between changes with Go to Next Difference () and Go to Previous Difference (⇧F7 (Windows, Linux Shift+F7)). Lines can be navigated with arrow keys and pressing Enter will jump back in the Diff editor and the selected line.

Note: This experience is especially helpful for screen reader users.

Git output window

You can always peek under the hood to see the Git commands we are using. This is helpful if something strange is happening or if you are just curious. :)

To open the Git output window, run View > Output and select Git from the drop-down list.

Initialize a repository

If your workspace isn't under Git source control, you can easily create a Git repository with the Initialize Repository command. When VS Code doesn't detect an existing Git repository, you will see a There are no active source control providers. message in the Source Control view and the Initialize Repository command will be available on the title bar. You can also run the Git: Initialize Repository command from the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)).

Running Initialize Repository will create the necessary Git repository metadata files and show your workspace files as untracked changes ready to be staged.

VS Code as Git editor

When you launch VS Code from the command line, you can pass the --wait argument to make the launch command wait until you have closed the new VS Code instance. This can be useful when you configure VS Code as your Git external editor so Git will wait until you close the launched VS Code instance.

Here are the steps to do so:

1. Make sure you can run code --help from the command line and you get help.
if you do not see help, please follow these steps:

macOS: Select Shell Command: Install 'Code' command in path from the Command Palette.

Windows: Make sure you selected Add to PATH during the installation.

Linux: Make sure you installed Code via our new .deb or .rpm packages.

2. From the command line, run git config --global core.editor "code --wait"

Now you can run git config --global -e and use VS Code as editor for configuring Git.

VS Code as Git diff tool

Add the following to your Git configurations to use VS Code as the diff tool:

[diff] tool = default-difftool [difftool "default-difftool"] cmd = code --wait --diff $LOCAL $REMOTE

This leverages the --diff option you can pass to VS Code to compare 2 files side by side.

To summarize, here are some examples of where you can use VS Code as the editor:

git rebase HEAD~3 -i do interactive rebase using VS Code

git commit use VS Code for the commit message

git add -p followed by e for interactive add

git difftool <commit>^ <commit> use VS Code as the diff editor for changes

Working with pull requests

Visual Studio Code also supports pull request workflows through extensions available on the VS Code Marketplace. Pull request extensions let you review, comment, and verify source code contributions directly within VS Code.

Tip: Click on an extension tile to read the description and reviews in the Marketplace.

Next steps

Common questions

To push, pull, and sync you need to have a Git origin set up. You can get the required URL from the repo host. Once you have that URL, you need to add it to the Git settings by running a couple of command line actions. For example:

> git remote add origin https://github.com/<repo owner>/<repo name>.git > git push -u origin master

My team is using Team Foundation Version Control (TFVC) instead of Git. What should I do?

Use the Azure Repos extension and this will light up TFVC support.

Why do the Pull, Push and Sync actions never finish?

This usually means there is no credential management configured in Git and you're not getting credential prompts for some reason.

You can always set up a credential helper in order to pull and push from a remote server without having VS Code prompt for your credentials each time.

How can I sign into Git with my Azure DevOps organization which requires multi-factor authentication?

There are now Git credential helpers that assist with multi-factor authentication. You can download these from Git Credential Manager for Mac and Linux and Git Credential Manager for Windows.

I have GitHub Desktop installed on my computer but VS Code ignores it

VS Code only supports the official Git distribution for its Git integration.

I keep getting Git authentication dialogs whenever VS Code is running

VS Code automatically fetches changes from the server in order to present you with a summary of incoming changes. The Git authentication dialog is independent from VS Code itself and is a part of your current Git credential helper.

One way to avoid these prompts is to set up a credential helper which remembers your credentials.

Another option is to disable the auto fetch feature by changing the following setting: "git.autofetch": false.

Can I use SSH Git authentication with VS Code?

Yes, though VS Code works most easily with SSH keys without a passphrase. If you have a SSH key with a passphrase, you'll need to launch VS Code from a Git Bash prompt to inherit its SSH environment.

# data[].attributes.attachment_link.description
Visual Studio Code has integrated source control and includes Git support in-the-box. Many other source control providers are available through extensions on the VS Code Marketplace. Tip: Click on an extension tile to read the description and reviews in the Marketplace. VS Code has support for handling multiple Source Control providers simultaneously.

# data[].attributes.attachment_link.title
Working with GitHub in Visual Studio Code

# data[].attributes.attachment_link.description
Working with GitHub in Visual Studio Code

# data[].attributes.attachment_link.readable_text
The Visual Studio Code Remote - Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set. A devcontainer.json file in your project tells VS Code how to access (or create) a development container with a well-defined tool and runtime stack. This container can be used to run an application or to separate tools, libraries, or runtimes needed for working with a codebase.

Workspace files are mounted from the local file system or copied or cloned into the container. Extensions are installed and run inside the container, where they have full access to the tools, platform, and file system. This means that you can seamlessly switch your entire development environment just by connecting to a different container.

This lets VS Code provide a local-quality development experience including full IntelliSense (completions), code navigation, and debugging regardless of where your tools (or code) are located.

Getting started

Note: After reviewing this topic, you can get started with the introductory Containers tutorial.

System requirements
Local / Remote Host:

Windows: Docker Desktop 2.0+ on Windows 10 Pro/Enterprise. Windows 10 Home (2004+) requires Docker Desktop 2.3+ and the WSL 2 back-end. (Docker Toolbox is not supported. Windows container images are not supported.)

macOS: Docker Desktop 2.0+.

Linux: Docker CE/EE 18.06+ and Docker Compose 1.21+. (The Ubuntu snap package is not supported.)

Remote hosts: 1 GB RAM is required, but at least 2 GB RAM and a 2-core CPU is recommended.

Other Docker compliant CLIs may work, but are not officially supported. Note that attaching to a Kubernetes cluster only requires a properly configured kubectl CLI.

Containers:

x86_64 / ARMv7l (AArch32) / ARMv8l (AArch64) Debian 9+, Ubuntu 16.04+, CentOS / RHEL 7+

x86_64 Alpine Linux 3.9+

Other glibc based Linux containers may work if they have needed Linux prerequisites.

Installation

To get started, follow these steps:

1. Install and configure Docker for your operating system.

Windows / macOS:

1. Install Docker Desktop for Windows/Mac.

2. If you are using WSL 2 on Windows, to ensure the WSL 2 back-end is enabled: Right-click on the Docker taskbar item and select Settings. Check Use the WSL 2 based engine and verify your distribution is enabled under Resources > WSL Integration.

3. When not using the WSL 2 back-end, right-click on the Docker task bar item, select Settings and update Resources > File Sharing with any locations your source code is kept. See tips and tricks for troubleshooting.

Linux:

1. Follow the official install instructions for Docker CE/EE for your distribution. If you are using Docker Compose, follow the Docker Compose directions as well.

2. Add your user to the docker group by using a terminal to run: sudo usermod -aG docker $USER

3. Sign out and back in again so your changes take effect.

2. Install Visual Studio Code or Visual Studio Code Insiders.

3. Install the Remote Development extension pack.

Working with Git?

Here are two tips to consider:

If you are working with the same repository both locally in Windows and inside a container, be sure to set up consistent line endings. See tips and tricks for details.

If you clone using a Git credential manager, your container should already have access to your credentials! If you use SSH keys, you can also opt in to sharing them. See Sharing Git credentials with your container for details.

Working with Containers

The Remote - Containers extension supports two primary operating models:

Quick start: Try a development container

The easiest way to get started is to try one of the sample development containers. The Containers tutorial will walk you through setting up Docker and the Remote - Containers extension and let you select a sample:

Note: If you already have VS Code and Docker installed, then you may use open in dev container. You can learn more about this and how to add it to your repos in the create a dev container guide.

Quick start: Open an existing folder in a container

This quick start covers how to set up a dev container for an existing project to use as your full-time development environment using existing source code on your filesystem. Follow these steps:

1. Start VS Code, run the Remote-Containers: Open Folder in Container... command from the Command Palette (F1) or quick actions Status bar item, and select the project folder you would like to set up the container for.

Tip: If you want to edit the container's contents or settings before opening the folder, you can run Remote-Containers: Add Development Container Configuration Files... instead.

2. Now pick a starting point for your dev container. You can either select a base dev container definition from a filterable list, or use an existing Dockerfile or Docker Compose file if one exists in the folder you selected.

Note: When using Alpine Linux containers, some extensions may not work due to glibc dependencies in native code inside the extension.

The list will be automatically sorted based on the contents of the folder you open.

You may be able to customize your dev container with additional features, which you can read more about below.

The dev container definitions displayed come from the vscode-dev-containers repository. You can browse the containers folder of that repository to see the contents of each definition.

3. After picking the starting point for your container, VS Code will add the dev container configuration files to your project (.devcontainer/devcontainer.json).

4. The VS Code window will reload and start building the dev container. A progress notification provides status updates. You only have to build a dev container the first time you open it; opening the folder after the first successful build will be much quicker.

5. After the build completes, VS Code will automatically connect to the container.

You can now interact with your project in VS Code just as you could when opening the project locally. From now on, when you open the project folder, VS Code will automatically pick up and reuse your dev container configuration.

Tip: Want to use a remote Docker host? See the section on opening a folder on a remote SSH host in a container for information.

While using this approach to bind mount the local filesystem into a container is convenient, it does have some performance overhead on Windows and macOS. There are some techniques that you can apply to improve disk performance, or you can open a repository in a container using an isolated container volume instead.

Open a WSL 2 folder in a container on Windows

If you are using Windows Subsystem for Linux v2 (WSL 2) and have enabled Docker Desktop's WSL 2 back-end, you can work with source code stored inside WSL!

Once the WSL 2 engine is enabled, you can either:

Use the Remote-Containers: Reopen Folder in Container command from a folder already opened using the Remote - WSL extension.

Select Remote-Containers: Open Folder in Container... from the Command Palette (F1) and choose a WSL folder using the local \\wsl$ share (from the Windows side).

The rest of the quick start applies as-is! You can learn more about the Remote - WSL extension in its documentation.

Open a folder on a remote SSH host in a container

If you are using a Linux or macOS SSH host, you can use the Remote - SSH and Remote - Containers extensions together. You do not even need to have a Docker client installed locally.

To do so:

1. Follow the installation and SSH host setup steps for the Remote - SSH extension.

2. Optional: Set up SSH key based authentication to the server so you do not need to enter your password multiple times.

3. Install Docker on your SSH host. You do not need to install Docker locally.

4. Follow the quick start for the Remote - SSH extension to connect to a host and open a folder there.

5. Use the Remote-Containers: Reopen in Container command from the Command Palette (F1, ⇧⌘P (Windows, Linux Ctrl+Shift+P)).

The rest of the Remote - Containers quick start applies as-is. You can learn more about the Remote - SSH extension in its documentation. You can also see the Develop on a remote Docker host article for other options if this model does not meet your needs.

Open an existing workspace in a container

You can also follow a similar process to open a VS Code multi-root workspace in a single container if the workspace only references relative paths to sub-folders of the folder the .code-workspace file is in (or the folder itself).

You can either:

Use the Remote-Containers: Open Workspace in Container... command.

Use File > Open Workspace... once you have opened a folder that contains a .code-workspace file in a container.

Once connected, you may want to add the .devcontainer folder to the workspace so you can easily edit its contents if it is not already visible.

Also note that, while you cannot use multiple containers for the same workspace in the same VS Code window, you can use multiple Docker Compose managed containers at once from separate windows.

Quick start: Open a Git repository or GitHub PR in an isolated container volume

While you can open a locally cloned repository in a container, you may want to work with an isolated copy of a repository for a PR review or to investigate another branch without impacting your work.

Repository Containers use isolated, local Docker volumes instead of binding to the local filesystem. In addition to not polluting your file tree, local volumes have the added benefit of improved performance on Windows and macOS. (See Advanced Configuration Improve disk performance article for information on how to use these types of volumes in other scenarios.)

For example, follow these steps to open one of the "try" repositories in a Repository Container:

1. Start VS Code and run Remote-Containers: Clone Repository in Container Volume... from the Command Palette (F1).

2. Enter microsoft/vscode-remote-try-node (or one of the other "try" repositories), a Git URI, a GitHub branch URL, or a GitHub PR URL in the input box that appears and press Enter.

Tip: If you choose a private repository, you may want to setup a credential manager or add your SSH keys to your SSH agent. See Sharing Git credentials with your container.

3. If your repository does not have a .devcontainer/devcontainer.json file in it, you'll be asked to pick a starting point from a filterable list or an existing Dockerfile or Docker Compose file (if one exists).

Note: When using Alpine Linux containers, some extensions may not work due to glibc dependencies in native code inside the extension.

The list will be automatically sorted based on the contents of the folder you open. Note the dev container definitions displayed come from the vscode-dev-containers repository. You can browse the containers folder of that repository to see the contents of each definition.

4. The VS Code window (instance) will reload, clone the source code, and start building the dev container. A progress notification provides status updates.

If you pasted in a GitHub pull request URL in step 2, the PR will be automatically checked out and the GitHub Pull Requests extension will be installed in the container. The extension provides additional PR related features like a PR explorer, interacting with PR comments inline, and status bar visibility.

5. After the build completes, VS Code will automatically connect to the container. You can now work with the repository source code in this independent environment as you would if you had cloned the code locally.

Note that if the container fails to come up due to something like a Docker build error, you can select Reopen in Recovery Container in the dialog that appears to go into a "recovery container" that allows you to edit your Dockerfile or other content. This opens the docker volume with the cloned repository in a minimal container and shows you the creation log. Once you are done fixing, use Reopen in Container to retry.

Tip: Want to use a remote Docker host? See the section on opening a folder on a remote SSH host in a container for information.

Trusting your Workspace

Visual Studio Code takes security seriously and wants to help you safely browse and edit code no matter the source or original authors. The Workspace Trust feature lets you decide whether your project folders should allow or restrict automatic code execution.

The Remote - Containers extension has adopted Workspace Trust. Depending on how you open and interact with your source code, you'll be prompted to decide if you trust the code you're editing or executing at different points.

Reopen folder in container

Setting up a dev container for an existing project requires trusting the local (or WSL) folder. You will be asked to trust the local (or WSL) folder before the window reloads.

There are a couple of exceptions to this flow:

1. When clicking on a recent entry.

2. Using the Open Folder in Container command will ask for trust after the window reloads, if trust is not already given.

Attach to existing container

When attaching to an existing container, you will be asked to confirm that attaching means you trust the container. This is only confirmed once.

Clone repository in a volume

When cloning a repository in a container volume, you are asked to confirm that cloning a repository means you trust the repository. This is only confirmed once.

Inspect volume

Inspecting a volume starts in Restricted Mode, and you can trust the folder inside the container.

Docker daemon running remotely

This implies trusting the machine the Docker daemon runs on. There are no additional prompts to confirm (only those listed for the local/WSL case above).

Create a devcontainer.json file

VS Code's container configuration is stored in a devcontainer.json file. This file is similar to the launch.json file for debugging configurations, but is used for launching (or attaching to) your development container instead. You can also specify any extensions to install once the container is running or post-create commands to prepare the environment. The dev container configuration is either located under .devcontainer/devcontainer.json or stored as a .devcontainer.json file (note the dot-prefix) in the root of your project.

You can use any image, Dockerfile, or set of Docker Compose files as a starting point. Here is a simple example that uses one of the pre-built VS Code Development Container images:

Selecting the Remote-Containers: Add Development Container Configuration Files... command from the Command Palette (F1) will add the needed files to your project as a starting point, which you can further customize for your needs. The command lets you pick a pre-defined container configuration from a list based on your folder's contents, reuse an existing Dockerfile, or reuse an existing Docker Compose file.

To learn more about creating devcontainer.json files, see Create a Development Container.

Dev container features (preview)

Dev container features provide a smooth path for customizing your container definitions.

When you use Remote-Containers: Add Development Container Configuration Files, you're presented a list of scripts to customize the existing dev container configurations, such as installing Git or the Azure CLI:

When you rebuild and reopen in your container, the features you selected will be available in your devcontainer.json:

You'll get IntelliSense when editing the "features" property in the devcontainer.json directly:

Built-in features are sourced from the script library folder in the vscode-dev-containers repo, but the Remote - Containers extension and GitHub Codespaces include an early preview for creating your own dev container features. For example, you can reference these as follows:

The form and format of these custom features is still in flux, but you can try creating your own dev container feature using the dev-container-features-template sample repository. Let us know what you think!

The Remote-Containers: Configure Container Features command allows you to update an existing configuration.

Pre-building dev container images

We recommend pre-building images with the tools you need rather than creating and building a container image each time you open your project in a dev container. Using pre-built images will result in a faster container startup, simpler configuration, and allows you to pin to a specific version of tools to improve supply-chain security and avoid potential breaks. You can automate pre-building your image by scheduling the build using a DevOps or continuous integration (CI) service like GitHub Actions.

We recommend using the devcontainer CLI to pre-build your images since it is kept in sync with the Remote - Container extension's latest capabilities - including dev container features. Once you've built your image, you can push it to a container registry (like the Azure Container Registry, GitHub Container Registry, or Docker Hub) and reference it directly.

See the devcontainer CLI article on pre-building images for more information.

Inspecting volumes

Occasionally you may run into a situation where you are using a Docker named volume that you want to inspect or make changes in. You can use VS Code to work with these contents without creating or modifying devcontainer.json file by selecting the Remote-Containers: Explore a Volume in a Development Container... from the Command Palette (F1).

You can also inspect your volumes in the Remote Explorer. Make sure you have Containers selected in the dropdown, then you'll notice a Dev Volumes section. You can right-click on a volume to inspect its creation information, like when the volume was created, what repo was cloned into it, and the mountpoint. You can also explore it in a dev container.

If you have the Docker extension installed, you can right-click on a volume in the Volumes section of the Docker Explorer and select Explore in a Development Container.

Managing extensions

VS Code runs extensions in one of two places: locally on the UI / client side, or in the container. While extensions that affect the VS Code UI, like themes and snippets, are installed locally, most extensions will reside inside a particular container. This allows you to install only the extensions you need for a given task in a container and seamlessly switch your entire tool-chain just by connecting to a new container.

If you install an extension from the Extensions view, it will automatically be installed in the correct location. You can tell where an extension is installed based on the category grouping. There will be a Local - Installed category and also one for your container.

Note: If you are an extension author and your extension is not working properly or installs in the wrong place, see Supporting Remote Development for details.

Local extensions that actually need to run remotely will appear Disabled in the Local - Installed category. Select Install to install an extension on your remote host.

You can also install all locally installed extensions inside the Dev Container by going to the Extensions view and selecting Install Local Extensions in Dev Container: {Name} using the cloud button at the right of the Local - Installed title bar. This will display a dropdown where you can select which locally installed extensions to install in your container.

However, some extensions may require you to install additional software in the container. Consult extension documentation for details if you encounter issues.

Adding an extension to devcontainer.json

While you can edit your devcontainer.json file by hand to add a list of extension IDs, you can also right-click on any extension in the Extensions view and select Add to devcontainer.json.

"Always installed" extensions

If there are extensions that you would like always installed in any container, you can update the remote.containers.defaultExtensions User setting. For example, if you wanted to install the GitLens and Resource Monitor extensions, you would specify their extension IDs as follows:

"remote.containers.defaultExtensions" : [ "eamodio.gitlens" , "mutantdino.resourcemonitor" ]

Advanced: Forcing an extension to run locally or remotely

Extensions are typically designed and tested to either run locally or remotely, not both. However, if an extension supports it, you can force it to run in a particular location in your settings.json file.

For example, the setting below will force the Docker extension to run locally and Debugger for Chrome extension to run remotely instead of their defaults:

A value of "ui" instead of "workspace" will force the extension to run on the local UI/client side instead. Typically, this should only be used for testing unless otherwise noted in the extension's documentation since it can break extensions. See the section on preferred extension location for details.

Forwarding or publishing a port

Containers are separate environments, so if you want to access a server, service, or other resource inside your container, you will need to either "forward" or " publish" the port to your host. You can either configure your container to always expose these ports or just forward them temporarily.

Always forwarding a port

You can specify a list of ports you always want to forward when attaching or opening a folder in container by using the forwardPorts property in devcontainer.json.

Simply reload / reopen the window and the setting will be applied when VS Code connects to the container.

Temporarily forwarding a port

If you need to access a port that you didn't add to devcontainer.json or publish in your Docker Compose file, you can temporarily forward a new port for the duration of the session by running the Forward a Port command from the Command Palette (F1).

After selecting a port, a notification will tell you the localhost port you should use to access the port in the container. For example, if you forwarded an HTTP server listening on port 3000, the notification may tell you that it was mapped to port 4123 on localhost. You can then connect to this remote HTTP server using http://localhost:4123.

This same information is available in the Forwarded Ports section of the Remote Explorer if you need to access it later.

If you would like VS Code to remember any ports you have forwarded, check Remote: Restore Forwarded Ports in the Settings editor () or set "remote.restoreForwardedPorts": true in settings.json.

Publishing a port

Docker has the concept of "publishing" ports when the container is created. Published ports behave very much like ports you make available to your local network. If your application only accepts calls from localhost, it will reject connections from published ports just as your local machine would for network calls. Forwarded ports, on the other hand, actually look like localhost to the application. Each can be useful in different situations.

To publish a port, you can:

In each case, you'll need to rebuild your container for the setting to take effect. You can do this by running the Remote-Containers: Rebuild Container command in the Command Palette (F1) when you are connected to the container.

Opening a terminal

Opening a terminal in a container from VS Code is simple. Once you've opened a folder in a container, any terminal window you open in VS Code ( Terminal > New Terminal) will automatically run in the container rather than locally.

You can also use the code command line from this same terminal window to perform a number of operations such as opening a new file or folder in the container. Type code --help to learn what options are available from the command line.

Debugging in a container

Once you've opened a folder in a container, you can use VS Code's debugger in the same way you would when running the application locally. For example, if you select a launch configuration in launch.json and start debugging (), the application will start on the remote host and attach the debugger to it.

See the debugging documentation for details on configuring VS Code's debugging features in .vscode/launch.json.

Container specific settings

VS Code's local user settings are also reused when you are connected to a dev container. While this keeps your user experience consistent, you may want to vary some of these settings between your local machine and each container. Fortunately, once you have connected to a container, you can also set container-specific settings by running the Preferences: Open Remote Settings command from the Command Palette (F1) or by selecting the Remote tab in the Settings editor. These will override any local settings you have in place whenever you connect to the container.

Default container specific settings

You can include defaults for container specific settings in devcontainer.json using the settings property. These values will be automatically placed in the container specific settings file inside the container once it is created.

For example, adding this to .devcontainer/devcontainer.json will set the Java home path:

Since this just establishes the default, you are still able to change the settings as needed once the container is created.

Sharing Git credentials with your container

The Remote - Containers extension provides out of box support for using local Git credentials from inside a container. In this section, we'll walk through the two supported options.

If you do not have your user name or email address set up locally, you may be prompted to do so. You can do this on your local machine by running the following commands:

git config --global user.name "Your Name" git config --global user.email "your.email@address"

The extension will automatically copy your local .gitconfig file into the container on startup so you should not need to do this in the container itself.

Using a credential helper

If you use HTTPS to clone your repositories and have a credential helper configured in your local OS, no further setup is required. Credentials you've entered locally will be reused in the container and vice versa.

Using SSH keys

There are some cases when you may be cloning your repository using SSH keys instead of a credential helper. To enable this scenario, the extension will automatically forward your local SSH agent if one is running.

You can add your local SSH keys to the agent if it is running by using the ssh-add command. For example, run this from a terminal or PowerShell:

On Windows and Linux, you may get an error because the agent is not running (macOS typically has it running by default). Follow these steps to resolve the problem:

Windows:

Start a local Administrator PowerShell and run the following commands:

# Make sure you're running as an Administrator Set-Service ssh-agent -StartupType Automatic Start-Service ssh-agent Get-Service ssh-agent
Linux:
First, start the SSH Agent in the background by running the following in a terminal:

Then add these lines to your ~/.bash_profile or ~/.zprofile (for Zsh) so it starts on login:

Sharing GPG Keys

If you want to GPG sign your commits, you can share your local keys with your container as well. You can find out about signing using a GPG key in GitHub's documentation.

If you do not have GPG set up, you can configure it for your platform:

On Windows, you can install Gpg4win.

On macOS, you can install GPG Tools.

On Linux, locally install the gnupg2 package using your system's package manager.

On WSL:

Install Gpg4win on the Windows side.

Install gpg in your WSL distro. sudo apt install gpg

Register a pinentry GUI in your WSL distro. echo pinentry-program /mnt/c/Program\ Files\ \(x86\)/Gpg4win/bin/pinentry.exe > ~/.gnupg/gpg-agent.conf

Reload the gpg agent in WSL. gpg-connect-agent reloadagent /bye

Next, install gnupg2 in your container by updating your Dockerfile.

For example:

RUN apt-get update && apt-get install gnupg2 -y

Or if running as a non-root user:

RUN sudo apt-get update && sudo apt-get install gnupg2 -y

The next time the container starts, your GPG keys should be accessible inside the container as well.

Note: If you used gpg previously in the container, you may need to run Remote-Containers: Rebuild Container for the update to take effect.

Managing containers

By default, the Remote - Containers extension automatically starts the containers mentioned in the devcontainer.json when you open the folder. When you close VS Code, the extension automatically shuts down the containers you've connected to. You can change this behavior by adding "shutdownAction": "none" to devcontainer.json.

While you can use the command line to manage your containers, you can also use the Remote Explorer. To stop a container, select Containers from the dropdown (if present), right-click on a running container, and select Stop Container. You can also start exited containers, remove containers, and remove recent folders. From the Details view, you can forward ports and open already forwarded ports in the browser.

If you want to clean out images or mass-delete containers, see Cleaning out unused containers and images for different options.

Personalizing with dotfile repositories

Dotfiles are files whose filename begins with a dot (.) and typically contain configuration information for various applications. Since development containers can cover a wide range of application types, it can be useful to store these files somewhere so that you can easily copy them into a container once it is up and running.

A common way to do this is to store these dotfiles in a GitHub repository and then use a utility to clone and apply them. The Remote - Containers extension has built-in support for using these with your own containers. If you are new to the idea, take a look at the different dotfiles bootstrap repositories that exist.

To use it, add your dotfiles GitHub repository to VS Code's User Settings () as follows:

Or in settings.json:

From this point forward, the dotfiles repository will be used whenever a container is created.

Advanced container configuration

See the Advanced container configuration articles for information on the following topics:

devcontainer.json reference

There is a full devcontainer.json reference, where you can review the file schema to help you customize your development containers and control how you attach to running containers.

Known limitations

Remote - Containers limitations

Windows container images are not yet supported.

All roots/folders in a multi-root workspace will be opened in the same container, regardless of whether there are configuration files at lower levels.

The unofficial Ubuntu Docker snap package for Linux is not supported. Follow the official Docker install instructions for your distribution.

Docker Toolbox on Windows is not supported.

If you clone a Git repository using SSH and your SSH key has a passphrase, VS Code's pull and sync features may hang when running remotely. Either use an SSH key without a passphrase, clone using HTTPS, or run git push from the command line to work around the issue.

Local proxy settings are not reused inside the container, which can prevent extensions from working unless the appropriate proxy information is configured (for example global HTTP_PROXY or HTTPS_PROXY environment variables with the appropriate proxy information).

You cannot use Remote - Containers from a Remote - SSH connection to a Windows machine.

See here for a list of active issues related to Containers.

Docker limitations

First-time installs of Docker Desktop for Windows when not using the WSL 2 engine will require an additional "sharing" step to give your container access to local source code. However, this step may not work with certain AAD (email-based) identities. See Docker Desktop for Windows tips and Enabling file sharing in Docker Desktop for details and workarounds.

You may see errors if you sign in to Docker with your email address instead of your Docker ID. This is a known issue and can be resolved by signing in with your Docker ID instead. See Docker issue #935 for details.

If you see high CPU spikes for com.docker.hyperkit on macOS, this may be due to a known issue with Docker for Mac. See the Docker issue for details.

See the Docker troubleshooting guide for Windows or Mac, consult Docker Support Resources for more information.

Docker Extension limitations

If you are using the Docker or Kubernetes extension from a Remote - WSL or Remote - SSH window, you will not be able to use the right-click Attach to Container option. This will only work if you are using it from your local machine.

Extension limitations

Many extensions will work inside dev containers without modification. However, in some cases, certain features may require changes. If you run into an extension issue, see here for a summary of common problems and solutions that you can mention to the extension author when reporting the issue.

In addition, while Alpine support is available, some extensions installed in the container may not work due to glibc dependencies in native code inside the extension. See the Remote Development with Linux article for details.

Common questions

I am seeing errors when trying to mount the local filesystem into a container

Right-click on the Docker task bar item. On Windows, select the Settings menu item then Resources > File Sharing and check the drive(s) where your source code is located. On macOS, select the Preferences menu item then Resources > File Sharing and make sure the folder containing your source code is under a file path specified in the list.

See Docker Desktop for Windows tips for information on workarounds to common Docker for Windows issues.

I'm seeing an error about a missing library or dependency

Some extensions rely on libraries not found in specific Docker images. For example, Visual Studio Live Share requires the installation of system-level dependencies, which are listed in their documentation. The need for these dependencies may depend on the operating system (for example, specific Linux distribution) used by your Docker image. You may need to install these dependencies during the Docker build process, by adding required commands to your Dockerfile. Search the specific extension's documentation to check for dependencies and see Installing additional software for help with resolving the problem.

Can I connect to multiple containers at once?

A VS Code window can only connect to one window currently, but you can open a new window and attach to an already running container or use a common Docker Compose file with multiple devcontainer.json files to automate the process a bit more.

Can I work with containers on a remote host?

Yes, see the section on opening a folder on a remote SSH host in a container for information.

How can I build or deploy container images into my local Docker / Kubernetes install when working inside a container?

You can build images and deploy containers by forwarding the Docker socket and installing the Docker CLI (and kubectl for Kubernetes) in the container. See the Docker-from-Docker, Docker-from-Docker Compose, and Kubernetes-Helm dev container definitions for details.

What are the connectivity requirements for the VS Code Server when it is running in a container?

Installation of VS Code Server requires that your local machine have outbound HTTPS (port 443) connectivity to:

The Remote - Containers extensions will download VS Code Server locally and copy it to the container once connected.

You can install extensions manually without an internet connection using the Extensions: Install from VSIX... command, but if you use the extension panel or devcontainer.json to install extensions, your local machine and VS Code Server will need outbound HTTPS (port 443) access to:

marketplace.visualstudio.com

*.vo.msecnd.net (Azure CDN)

*.gallerycdn.vsassets.io (Azure CDN)

Finally, some extensions (like C#) download secondary dependencies from download.microsoft.com or download.visualstudio.microsoft.com. Others (like Visual Studio Live Share) may have additional connectivity requirements. Consult the extension's documentation for details if you run into trouble.

VS Code Server runs on a random port inside the container and VS Code itself uses docker exec to communicate with it over Docker's configured communication channel.

As an extension author, what do I need to do to make sure my extension works?

The VS Code extension API hides most of the implementation details of running remotely so many extensions will just work inside dev containers without any modification. However, we recommend that you test your extension in a dev container to be sure that all of its functionality works as expected. See the article on Supporting Remote Development for details.

What other resources are there that may be able to answer my question?

The following articles may help answer your question:

Questions or feedback

Next steps

# data[].attributes.attachment_link.title
Developing inside a Container using Visual Studio Code Remote Development

# data[].attributes.attachment_link.description
The Visual Studio Code Remote - Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code's full feature set.

# data[].attributes.attachment_link.readable_text
The Docker extension makes it easy to build, manage, and deploy containerized applications in Visual Studio Code.

This page provides an overview of the Docker extension capabilities; use the side menu to learn more about topics of interest. If you are just getting started with Docker development, try the Docker tutorial first to understand key Docker concepts.

Installation

Install Docker on your machine and add it to the system path.

On Linux, you should also enable Docker CLI for the non-root user account that will be used to run VS Code.

To install the extension, open the Extensions view (⇧⌘X (Windows, Linux Ctrl+Shift+X)), search for docker to filter results and select Docker extension authored by Microsoft.

Editing Docker files

You can get IntelliSense when editing your Dockerfile and docker-compose.yml files, with completions and syntax help for common commands.

In addition, you can use the Problems panel (⇧⌘M (Windows, Linux Ctrl+Shift+M)) to view common errors for Dockerfile and docker-compose.yml files.

Generating Docker files

You can add Docker files to your workspace by opening the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) and using Docker: Add Docker Files to Workspace command. The command will generate Dockerfile and .dockerignore files and add them to your workspace. The command will also ask you if you want to add Docker Compose files as well, but this is optional.

The extension can scaffold Docker files for most popular development languages (C#, Node.js, Python, Ruby, Go, and Java) and customizes the generated Docker files accordingly. When these files are created, we also create the necessary artifacts to provide debugging support for Node.js, Python, and .NET (C#).

Docker Explorer

The Docker extension contributes a Docker Explorer view to VS Code. The Docker Explorer lets you examine and manage Docker assets: containers, images, volumes, networks, and container registries. If the Azure Account extension is installed, you can browse your Azure Container Registries as well.

The right-click menu provides access to commonly used commands for each type of asset.

You can rearrange the Docker Explorer panes by dragging them up or down with a mouse and use the context menu to hide or show them.

Docker commands

Many of the most common Docker commands are built right into the Command Palette:

You can run Docker commands to manage images, networks, volumes, image registries, and Docker Compose. In addition, the Docker: Prune System command will remove stopped containers, dangling images, and unused networks and volumes.

Docker Compose

Docker Compose lets you define and run multi-container applications with Docker. Our Compose Language Service in the Docker extension gives you IntelliSense and tab completions when authoring docker-compose.yml files. Press ⌃Space (Windows, Linux Ctrl+Space) to see a list of valid Compose directives.

We also provide tooltips when you hover over a Docker Compose YAML attribute.

While Compose Up allows you to run all of your services at once, our new feature Compose Up - Select Services lets you select any combination of the services you want to run.

Once your Compose Up command completes, navigate to the Docker Explorer to view your services as a Compose Group. This allows you to start, stop, and view the logs of each service as a group.

Using image registries

You can display the content and push, pull, or delete images from Azure Container Registry, Docker Hub, GitLab, and more:

An image in an Azure Container Registry can be deployed to Azure App Service directly from VS Code. See Deploy images to Azure App Service to get started. For more information about how to authenticate to and work with registries, see Using container registries.

Debugging services running inside a container

You can debug services built using .NET (C#) and Node.js that are running inside a container. The extension offers custom tasks that help with launching a service under the debugger and with attaching the debugger to a running service instance. For more information, see Debug containerized apps and Customize the Docker extension.

Azure CLI integration

You can start Azure CLI (command-line interface) in a standalone, Linux-based container with Docker Images: Run Azure CLI command. This gives you access to the full Azure CLI command set in an isolated environment. For more information on available commands, see Get started with Azure CLI.

Next steps

Read on to learn more about

# data[].attributes.attachment_link.description
The Docker extension makes it easy to build, manage, and deploy containerized applications in Visual Studio Code. This page provides an overview of the Docker extension capabilities; use the side menu to learn more about topics of interest. If you are just getting started with Docker development, try the Docker tutorial first to understand key Docker concepts.