Using .NET Core SDK from Docker image
I mentioned a few posts ago that Microsoft tends to update the Docker images more frequently then the installers available for the .NET Core SDK. In this post I aim to show you how to use that image as a replacement for the installed version of the .NET Core SDK.
.NET Core SDK
It consists primarily of the dotnet command line utility and the runtime and tools that compliment it.
This post will deal with the SDK available as a docker image from the public repository at docker.com.
Wrapping the dotnet command
The approach I am going to offer is to wrap the dotnet command with a bash shell script. I use the dotnet command primarily on macOS and Linux so this works best for me. A similar approach is possible on Windows in PowerShell but I will leave that porting exercise to the reader.
Some features of the wrapper script are:
- Working directory – unless specified with the -w switch the working directory is assumed to be the current directory.
- Interactive mode – If the -it switch is used you will be dropped into an interactive terminal inside the container
- Runtime ID – if the restore sub-command is given a runtime ID of debian.8-x64 is provided for you automatically
- Image name and tag – by default the image used is microsoft/dotnet:latest unless overridden by the DOCKER_DOTNET_IMAGE and DOCKER_DOTNET_IMAGE_TAG environment variables
- Container name and lifecycle – the script names the container dotnet-wrapper and removes it after the command has completed running
- Local mounted directories – the script arranges for the following mounts so that the result can be felt on the local filesystem:
Local Directory Container Directory ~/.dotnet /root/.dotnet ~/.nuget /root/.nuget $WORK_DIR /app
- Exit code – if an error occurs the script arranges for the return code of the docker run command to be returned to the environment
The dotnet wrapper script is available here. Just rename it to exclude the .txt file extension and chmod it executable. Place it in your path and voila!
If you want to control which version of the SDK you are using. Remember you can control that with the environment variables above. The reason I made that available so that you can control it at the project level. You may have one project using one version of the SDK and a second project using a different version.
As I write this version 1.1.1 has just come out. This version deprecates the use of the project.json file in favor of MSBuild .csproj files. This is not hard to deal with. But it will require a different usage of the command line than before. For example, to run a test project do this with the wrapper script:
dotnet test wordsearch.Tests/wordsearch.Tests.csproj
Specifying a project dir does not seem to work as advertised, FYI.
By selectively managing what SDK Docker image you target you can easily use the dotnet command without having to install it. And you can have multiple versions available at the same time! Simply change the environment variables to point to whichever version of the SDK you would like to use.