Where's DNVM? Safely running multiple versions of the .NET Core SDK and Tooling with global.json

On July 27th both the ASP.NET Core and .NET Core 1.0 runtimes were officially released. They are now version 1.0 and are both supported frameworks. However, the "tooling" around .NET Core remains in a Preview state. However, it's really easy and safe to swap between command-line tooling versions.

• NET Core SDK = Develop apps with .NET Core and the SDK+CLI (Software Development Kit/Command Line Interface) tools
• .NET Core = Run apps with the .NET Core runtime

You'll see over on the .NET Advanced Downloads page the complete list of downloads including those for Windows, Mac, and several flavors of Linux. It's even supported on RedHat Enterprise Linux...it's surreal to see that RedHat even has .NET Core docs on their site.

Where's DNVM List?

A year ago before ASP.NET Core and .NET Core fully merged and the "dotnet" command line was created, there was a command line tool called "dnvm" or the .NET Version Manager. It would give you a list of the .NET Core runtimes you had installed and let you switch between them. While that exact style of functionality may return as the SDK and tools continues development, you can easily have multiple .NET Core SDKs and CLIs installed and switch between them on a per project basis.

For now, if you want the equivalent to "dnvm list" to see what .NET Core SDKs are installed at a system level, you'll look here.

Where is the .NET Core SDK installed?

When you install the .NET Core SDK on Windows it shows up in C:\Program Files\dotnet\sdk.

In this screenshot I have four .NET Core SDKs installed. The SDK that ships with .NET Core 1.0 is 1.0.0-preview2-003121. However, you'll note that I have two newer .NET SDKs installed. Since it's all open source, you can head over to https://github.com/dotnet/cli and scroll down a bit.

There are CI (continuous integration builds) and a complete table of versions that you can download. Be sure to check the Build Status and see that things are passing and healthy, but also have a reason for downloading a daily build.

Know WHY you want a daily build of the .NET Core SDK. Are you checking on a specific bug to see if it's fixed? Is there a new feature that you require?

I noticed a specific bug that was bothering me in the Preview 2 tooling. I like to use the new logging system and I like that it uses ANSI Colors when logging to the console. When I go "dotnet run" I get very nice output. However, when I used "dotnet test" or "dotnet watch," I would lose all my ANSI colors and just get plaintext. I commented on the GitHub issue here.

A cosmetic bug, but still annoying to me. The cool part is that when it was/is fixed, as it was with this pull request, I can get a build and install it without fear. So I went to https://github.com/dotnet/cli and installed 1.0.0-preview3-003180. Again, you can see this version in the first Windows Explorer screenshot above.

Side by Side .NET Core SDK installs and global.json

Now that I've got the new .NET Core SDK, I can check the version at the command line like this:

C:\>dotnet --version
1.0.0-preview2-003121

C:\>dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14383
 OS Platform: Windows
 RID:         win10-x64

Then I can go back to my app and use "dotnet watch" or "dotnet test" and see if the bug was really fixed in this version. But what if I don't want my app to use this new dotnet CLI?

I've got a global.json in the root of my solution in c:\lab2 that looks like this:

{
  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-preview2-003121"
  }
}

My projects are in src and my tests are in test, all underneath the main solution folder that contains this global.json file. If the "sdk" section didn't exist, running dotnet --version would pick up the latest one. I've "pinned" a specific version so when I run dotnet --version while I'm in this folder or below, I'll get exactly what I asked for.

It looks and works like this...read carefully..

C:\lab2>dotnet --version
1.0.0-preview2-003121

C:\lab2>cd ..

C:\>dotnet --version
1.0.0-preview3-003180

C:\>where dotnet
C:\Program Files\dotnet\dotnet.exe

See that? A little known Windows command line trick is the "where" command. You can say "where notepad" and if there are more than one on the PATH, you'll get a list. However, here there's just one dotnet.exe, but I get different results when I run it in different folders. Exactly how this works is explained in exquisite detail in Matt Warren's post "How the dotnet CLI tooling runs your code" but it LOOKS like this, as viewed in Process Explorer:

And when I change the version in global.json to the daily I downloaded?

This way I can have lots of projects bring driven by different versions of the "dotnet" command without having to type anything other than "dotnet run" or "dotnet test."

It also allows me to keep using the .NET 1.0 runtime that is released and supported, while quickly testing new tooling features and checking on fixed bugs like this ANSI one that was annoying me.

Sponsor: Many thanks to my friends at Stackify for sponsoring the feed this week! it’s what being a developer is all about so do it the best you can. That’s why Stackify built Prefix. No .NET profiler is easier or more powerful. You’re 2 clicks and $0 away, so build on! Prefix.io.