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.
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.
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.
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.
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.
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?
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 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.
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. From the wealth of dotnet images 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.
For my own sake, I like to tag the image with a shorter name, so that short name can be used in subsequent commands.
> 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.
The container is also named for convenience.
> 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.
When more commands need to be run, just attach to the container once it is started:
# 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.
Top comments (0)