Scott Hanselman

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

July 10, 2016 Comment on this post [15] Posted in DotNetCore | Open Source
Sponsored By

On June 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.

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?

image

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 ANSI-colored output. However, when I used "dotnet test" or "dotnet watch," I would lose all my ANSI colors from the same logging calls and just get plaintext. I commented on the GitHub issue here as it's clearly a bug.

ANSI Colors are lost with dotnet watch

It's a cosmetic bug on the way dotnet.exe works with child processes, but it was 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.

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

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.143xx
OS Platform: Windows
RID: win10-x64

Here I've got the version that shipped with .NET Core 1.0. I want to use the latest one, then 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 want my app to be driven by this new dotnet CLI?

I've got a global.json in the root of my solution in c:\lab2 that looks like this. I'm going to change the version to the new one in a moment.

{
"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.

If the sdk is "pinned" to a specific version that means that when I run dotnet --version while in this folder or below, I'll get the specific version I've asked for.

Now I'll go to https://github.com/dotnet/cli and install (for example) 1.0.0-preview3-003180. This daily build has the fix for that ANSI bug I care about. Again, you can see this version is installed by looking in the first Windows Explorer screenshot above, and in c:\program files\dotnet\sdk.

Remember that my global.json in my c:\lab2 folder specifies (pinned) preview2? Now running dotnet.exe 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? I get preview2 inside the lab2 folder but I get the latest anywhere else. But how?

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:

DotNet.exe picks up the SDK version from global.json

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

Here dotnet.exe uses the a newer installed SDK

The dotnet.exe application will look at global.json and then do the right thing. 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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
July 10, 2016 12:23
Wow. Hadn't realized DNVM was retired. The change pace in .NET is daunting. :)
July 10, 2016 14:58
I love to have only one command (dotnet), it makes more sense if you compare it with other technologies the open source community is used to work with. It would be cool that for Mac we would be able to use brew to install it instead of downloading an installer.

BTW the first sentence
On July 27th both the ASP.NET Core and .NET Core 1.0 runtimes were officially released
should be "On June 27th".
July 10, 2016 22:40
Thanks Federico!
July 11, 2016 11:28
Great post.
July 11, 2016 11:40
What's the best way to uninstall DNVM and older versions of dotnet CLI?
July 11, 2016 11:46
Is there a scheduled date for RTM of the tooling?

Last time I installed them my whole VS 2015 install got corrupted and I had to reinstall it from scratch. I first tried uninstalling just the tooling but that messed things up even more.
July 11, 2016 19:52
Why is the preview 3 not live on the main site? https://www.microsoft.com/net/core#windows
July 11, 2016 21:30
Nice Article!
July 12, 2016 7:54
Scott,

Isn't global.json going away with project.json?

Daniel
July 13, 2016 14:37
Chris,

Preview 3 is not released yet, you can track the status here.
July 13, 2016 18:49
What does the version of dotnet command represent as shown in

Microsoft .NET Core Shared Framework Host

Version : 1.0.1
Build : cee57bf6c981237d80aa1631cfe83cb9ba329f12
Usage: dotnet [common-options] [[options] path-to-application]

Common Options:
--help Display .NET Core Shared Framework Host help.
--version Display .NET Core Shared Framework Host version.
...


What's that version of?
July 13, 2016 23:12
Really useful info! Thanks scott! :)
July 13, 2016 23:13
Nice post! Thanks Scott!
July 15, 2016 23:10
Good stuff Scott! I've been following you ever since I saw your demo of ASP.NET Core. Even if you are a failed comedian you are hilarious. Keep it up super fancy pants!
July 16, 2016 6:15
Nice to hosts multiple versions together. It remember me working on RoR where RVM allows me to have multiple versions together. Good to see in dotnet too.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.