Docker Support in Visual Studio 2017

Having experimented with Docker on Windows about a year ago (on a Technical Preview of Windows Server 2016), I thought I’d take a quick look at how container support has evolved with the latest version of the operating system and dev tools. At the time the integration of Docker into Windows was fairly flaky (to be expected for such a bleeding edge technology), but I was able to get a relatively large Windows-dependent monolith to run inside a set of Windows Containers. Most of this involved crafting Dockerfiles and running docker commands manually (and eventually scripting these commands to automate the build process).

Docker tools are now included in Visual Studio, so you can enable Docker support in a new (web) project when you create it:

Alternatively, you can add Docker support after the fact from the project context menu:

Either way, you get the following:

• a default Dockerfile in your project. This is for packaging a container image for your service automatically.
• a default docker-compose.yml file in your solution. This is for orchestrating the topology and startup of all of the services in your solution.
• a docker-compose.ci.build.yml file in your solution. You can actually spin up a “build” container in order to run the dotnet commands to restore Nuget packages, build and publish (stage) your binaries and dependencies. This is great because now even the build process will be consistent across all developers machines (and the central build system), so in addition to eliminating the “runs on my machine” problem, it also alleviates any “builds on my machine” problems, where developers might have different tool versions or environment setup.

The first time you run, there’s a significant delay while the appropriate image files are downloaded, but this is a one-time hit.

Your service image contains a CLR debugger, which Visual Studio can hook up to, so you can step through your service code.

What’s interesting (and not a little surprising) is that if you’re targeting .NET Core, your image will target a Linux base image by default. Docker for Windows also defaults to running containers in a Linux Hyper-V VM, so when you hit F5 the container will run your .NET Core service on Linux, and you’ll be remote debugging into a Linux machine.

All very cool stuff, and works well right out of the box without too much fuss. Of course, you can also do all of this manually from the command-line if you prefer to develop in a lightweight editor like VSCode.