Containers

UPDATE (2020-04-08): With the 1.44 release of Visual Studio Code (and the corresponding Remote Containers release), the Insiders release is no longer needed as the . I have updated the post to reflect this (update made in vscode dev container on stable release 😁).

Introduction

In my previous post I gave some thoughts on using Visual Studio Code dev containers. Until very recently your source code needed to be cloned in Windows in order to be able to build and run dev containers with Visual Studio Code. While this has still been a great experience overall, I have hit a few edge cases where being able to have my source code in Linux (under WSL) and then create a dev container from there would have been a big help.

[Read More]

Visual Studio Code has support for Remote Development which is a really cool feature. You can connect to another machine via SSH and work with code there (the language services etc run remotely which is the really cool part!), connect to the Windows Subsystem for Linux, or run your development environment in containers (aka dev containers). The last of these is the topic for this post.

My team has been using dev containers quite heavily for the last few months and found a lot of benefits with them. They allow you to describe your development environment with a Dockerfile and run your tools, terminal and debugger inside that container whilst keeping the editor UI local. This image from the docs shows this split:

[Read More]