Where's DNVM? Safely running multiple versions of the .NET Core SDK and Tooling with global.json
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.
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 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.
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:
.NET Command Line Tools (1.0.0-preview2-003121)
Commit SHA-1 hash: 1e9d529bc5
OS Name: Windows
OS Version: 10.0.143xx
OS Platform: Windows
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" ],
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.
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:
And when I change the version in global.json to the daily I downloaded?
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.