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.

Buttery Biscuit base.Dockerfile

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

There it is, clear as mud.

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.

Give em the old switcheroo

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.

Thar she blows capin’

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)

Oh yeah, him

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

Incase you didn’t believe me

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.

7 thoughts on “VSCode .devcontainer using dotnet5.0/.Net 5

Add yours

  1. First of all, thank you very much for your article.
    If I did not miss anything, I followed your instructions 1:1. But I get the error message:
    su: user vscode does not exist

    Do you have an idea what is missing?

    Like

    1. Hm.. It sounds like the VS code .devcontainer creation didn’t work properly, or it couldn’t run it’s own internal stuff. “SU” is switch user, so its trying to swap to the VSCode user in the container that you run as. I’ve not seen this issue… is the container created successfully? if you run “docker ps -a” do you see a new container created for your dev work?

      Like

      1. So if I try to install Node while creating the image, I get the same error message. If I omit node, at least the image can be created.
        When starting a container via VS Code, I get the same error message again.
        And yes, I see that a new container instance was created.

        Like

  2. Please excuse me. I didn’t clone your repository but had VS Code create the files and then modify them myself. After switching to your files everything works.
    Thank you very much!

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: