.NET Core SDK 2 on Unsupported OS
Tags: netcore, docker, mac
Published: 2017-09-23 18:18:42

---
title: .NET Core SDK 2 on Unsupported OS
published: true
description: 
tags: .net-core, docker, mac
canonical_url: https://dgondotnet.blogspot.dk/2017/09/net-core-sdk-2-on-unsupported-os.html
---

I have been without a “proper development laptop for a while. But that fact did not prevent me from hacking my way around in my old iMac.

Do you know what would have prevented my hacking? The fact the the newer _.NET SDK 2.0_ would not install in my non-Sierra system.<br />
But it didn’t, want to know how?

## Living in the Past

I might be considered a "Windows guy" since that is what I run the most. However my hate for labels and love for different things make me do things like having an iMac as a home computer and a dual-booting (Windows 10 whatever-fancy-name-of-the-version-is and Ubuntu Mate Xenial) second-hand Lenovo laptop as a work laptop for the rest of the family.<br />
The iMac sits on its own desk on a common area of the house, so I tend to use it a lot lately.

I was upgrading some training material to the current times and few things are more present in the .NET arena than .NET Core and since 2.0 is still fresh and warm off the oven, in my made, made sense to go with it.

I set off to install the _.NET Core SDK 2.0_ (_SDK2_ from now on)in my mid-2010 iMac, when I found out that Yosemite is not supported and therefore, one cannot install the _SDK2_ in anything older than Sierra on a Mac.

As it happens, I run Yosemite because anything newer than 10.10 makes my veteran computer crawl and me wanting to murder people in the waiting.<br/>
Trust me, I tried newer versions and had to undergo the stupid pain of going back to a previous MacOS version because murder is still uncool.<br/>
So Yosemite will endure until the computer either gives-in or it gets sold.

## Looking at the Future

Would I just fold and run to my laptop, install _SDK2_ and roll with it admitting defeat? Hell, no!

I made a simple observation: _SDK2_ is "just" a bunch of command line utils.<br/>
With that observation in the back of my head I wondered: Is there an easy and performant enough way to run those utils outside my unsupported box while still remain local for the file editing?<br/>
I'll give you a hint: the answer I chose involves thinking __inside__ a _box_.

### Joining the craze

And by _box_, I mean container.

[One](https://www.microsoft.com/net/core#dockercmd) of the means to install _SDK2_ does not involve "installing" it in your system. One can run "something" that has the _SDK2_ inside so you can open a shell to it and still be able to access your filesystem while using your favorite editor in your box. That "something" is a container.

By running _Docker_ in your box, you can download an image with _SDK2_ (or, basically, whatever) and run `dotnet ...` commands in a remote shell, bypassing the fact that the underlying system, my oldie-but-goldie iMac, does not support such software.<br/>
And all that without dealing with virtual machines and virtual hard-drives in the size of gigabytes.

What is not to like?

#### Revealing the (command) lines

First thing one has to do is pull the right image from the [Docker Hub](https://hub.docker.com/). From the wealth of [dotnet images](https://hub.docker.com/r/microsoft/dotnet/) available, since we are building software, we need one labeled __sdk__ and a newer _stretch_ Linux since I really do not need to target the classic .NET Framework.<br/>
For my own sake, I like to tag the image with a shorter name, so that short name can be used in subsequent commands.

```sh
> docker pull microsoft/dotnet:2.0-sdk
# tag pulled image for easier usage
> docker tag microsoft/dotnet:2.0-sdk sdk2
```
Pulling the image takes some time that depends on your connection speed and your computing power.

With the image in our system, we need to run the container based on it, interactively with a terminal. If such command is run from the project folder, such folder will be mounted and available from the running container.<br/>
The container is also named for convenience.

```sh
> cd {project-folder}
> docker run -ti --name sdk2 --mount type=bind,source="$(pwd)",target=/root/{project-folder} sdk2
# this shell is in the running container
root@container-id#
```

Once in that terminal, `dotnet` commands can be run happily. When done running the commands, the session can be finised with `exit`, which will close the container terminal, stop the container and get us back to our shell.<br/>
When more commands need to be run, just attach to the container once it is started:

```sh
# close container session (container will stop)
root@container-id# exit
...
# reconnect to the stopped container
> $ docker start -a sdk2
```

One less excuse to embrace the command line.