VSCode .devcontainer using dotnet5.0/.Net 5

If, like me, you have recently discovered the power of the .devcontainer functionality of VS Code and it’s remote debugging, you will maybe be dismayed that there isn’t support for net5.0/.Net 5 yet. However, as we are developing a new API at the minute, that’s not yet released, we upgraded it to net5 to see what all the fuss is about. The upgrade went great, but doing so totally killed the .devcontainer I was using for some automated tests. Here’s how I fixed it.

Hol’ up…. what’s the problem?

So, if you don’t know what the whole ‘developing in a container’ thing is about read this article from visualstudio.com.

My scenario for using this is that I use docker compose (and a big ol’ bash script) to build a reproduction of our system’s environment…. our IdentityServer4 build, some of our APIs, a redis cache, a SQL server, imitation blob storage and imitation table storage (using the amazing azurite cross platform versions). When I create those, they are all on a bridge network, so they can all talk to eachother with by referencing their container name. It’s great, you just set up all your test urls to be "http://myidentityprovidercontainer_1" and the all connect with no major issues.

The .devcontainer is great, it allows me to run, debug and edit my code in the context of the container… so when I run my applications they are attached to the bridge network and can communicate as mentioned above. And all if have to do is edit .devcontainer.json and add in:

"runArgs": ["--network=my-dockercompose-api-network_default"],

However, when you create the .devcontainer you are limited to options of dotnet core 3.1 or 2.1. Which means, that after the upgrade to net5.0 … it barfed and wouldn’t work.

Trying to figure out what was the issue… I found the repo for the vs-code-dev-containers here and was able to fork a copy of it to my own github. That allowed me to dig around and find the folder for the dotnet core containers I was using. Which is found here:

vscode-dev-containers/containers/dotnetcore

Ok, so how do I fix this?

(I should note, that there is already a PR that contains a fix for net5.0 and I assume it will be much more fleshed out than my fix, however, this is a ‘how to get this up and running asap’ fix.)

In this library, you will find the base.Dockerfile as well as the Dockerfile that is run when you Open VSCode in a container.

It is from this base.Dockerfile that the Dockerfile builds its image. So if we look inside base.Dockerfile we can see the issue.

This docker image is using the old repo name of /dotnet/core/sdk and not the new updated one of dotnet/sdk which is where all of the new net5 stuff is located. (on a side note, I don’t really know whether to call that .Net 5, dotnet 5, net5.0 or something else… so I will probably use them all at some point, apologies).

As well as the wrong repo name for the image, there is a -bionic suffix to the tag, which relates to a particular build of Ubuntu (the image’s base). BUT…. if we look at the dotnet sdk docker repo… there is not 5.0 bionic… 5.0 has moved to focal. So we need to make a few changes here.

If you update the URL to be correct, and swap out bionic for focal, you can then build this image.

Now, when docker tries to pull an image, it will first check your local cache, before heading off somewhere like dockerhub to pull down a version. As we don’t have access to the mcr container repository, we are just going to build this image locally and store it, and not try to push it.

So if you use terminal and navigate to the /containers/dotnetcore/.devcontainer folder and run this command

docker build -f base.Dockerfile . -t mcr.microsoft.com/vscode/devcontainers/dotnetcore:0-5.0

You will build a local copy of the image, and tag it with 0-5.0.

You can confirm this works by running docker image ls which should show you the image you just built in your local docker image cache.

Cool… now what?

Well, the reason we added the -t argument to name and tag the image like that, is our Dockerfile that VSCode creates for us when we try to run in a container (the same docker file we saw earlier in the vscode-devcontainers repo)

It takes an argument of the image variant (dotnet version), and appends it to the image name… so now that we have built a successful 0-5.0 image, we can up the argument to 5.0.

There is also the .devcontainer.json file to consider as it’s what triggers the whole process and passes the argument to this file. So for my purposes, I just edited both devcontainer.json and the Dockerfile in my visual studio project to both say 5.0

So with all that, I deleted any container that was currently running the VS Code instance, and closed code. When I reopen it, I am prompted to “Reopen in Container” which I click, and it successfully builds the .devcontainer using my local 0-5.0 image that I created, and I can run my .Net5.0 app perfectly well.

tl;dr – Build a local copy of the devcontainer image, and then edit the files in your .devcontainer folder of your project.