DotNet / NetCore Versions

Well, the .NET Core 1.0 RTM release went out yesterday, and everything went just fine!

No, just kidding. When does the first major release of a new platform ever go just fine? :)

Currently, there’s a bit of confusion out there because the runtime (netcore) RTM’d, but the tooling (dotnet) is still in preview. I’m writing down how all the pieces fit together (along with recent history) so I can keep it all straight in my head.

So, this is my short reference blog post pointing out which versions of which go with what. And stuff.

The Right Bits

There have been several reports of odd Visual Studio behavior due to conflicting installs.

So, the first thing to do is to uninstall all old DNX or dotnet tooling, and any pre-release netcore runtimes. See the end of this post for uninstall helps.

Then, install the proper bits.

For a Windows machine running Visual Studio, the proper bits are Visual Studio 2015 Update 3 followed by the .NET Core for Visual Studio Official MSI Installer (which includes some RTM pieces and some preview pieces).

For a command-line setup, the proper bits are the .NET Core Runtime followed by the .NET Core SDK (which is in preview).

If you use ReSharper, be sure to upgrade to 2016.2 EAP 6.

DotNet and NetCore

As previously noted, .NET Core did RTM yesterday, but the DotNet tooling is still in preview. Here’s a rundown of the recent releases and how they match:

The tooling version is what should be referenced in your global.json. So a global.json targeting the current tooling release would look like:

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

The tooling version is also what gets reported from dotnet --version:

> dotnet --version
1.0.0-preview2-003121

Installing Tooling on CI Machines

Continuous Integration build servers also need to have the appropriate tooling installed. For a variety of reasons, I prefer to have my .NET Core projects locally install the exact version of tooling that they need.

The DotNet tooling has supported “scripted installs” via PowerShell / Bash scripts for a long time. It’s not too hard to install the tooling as part of your build script, if you know where the files are.

The basic idea is that you first download an “install” script and then invoke it with the desired “channel” and “version” to get the actual tooling.

The Bash install scripts are located in the same place, just with a .sh extension.

A full “install local” PowerShell script for the current tooling version would look something like this:

# Download the "dotnet-install.ps1" script.
Invoke-WebRequest "https://raw.githubusercontent.com/dotnet/cli/rel/1.0.0-preview2/scripts/obtain/dotnet-install.ps1" -OutFile ".\dotnet-install.ps1"

# Decide to install into a ".dotnetcli" local directory.
$env:DOTNET_INSTALL_DIR = "$pwd\.dotnetcli"

# Do the actual install.
& .\dotnet-install.ps1 -Channel "preview" -Version "1.0.0-preview2-003121" -InstallDir "$env:DOTNET_INSTALL_DIR"

Misc Tips

As a general rule, you want use the highest available release of the NETStandard.Library dependency (if you’re using it), but the lowest possible netstandard target (to reach the largest number of platforms). For more details, see the conceptual links below.

Helpful Links

If you have an upgrade problem that you just can’t figure out, join the (unofficial) .NET Core Slack channel or the (official) .NET Core Gitter room and ask on there.

Good luck!

Conceptual

All about netstandard

Packages, Metapackages, and Frameworks

Dependency Trimming

Upgrading

Upgrading to ASP.NET Core RTM from RC2 (Rick Strahl)

xUnit on .NET Core

OpenCover requires the -oldStyle flag to work on the .NET Core 1.0.0/RTM runtime

Moq 4.6.25-alpha is missing a dependency, so you need to declare it manually

[ASP.NET] Migrating from ASP.NET Core RC2 to ASP.NET Core 1.0

[ASP.NET] Migrating from ASP.NET 5 RC1 to ASP.NET Core 1.0

Migrating from DNX

Uninstalling Old versions

Some developers have reported that Visual Studio .NET Core RC2 will not uninstall without the MSI. If you need the MSI, you can get it from here.

Some developers have had problems with old uninstallers not cleaning up older versions of the tooling, and the problems with naming (where “RC1” and “RC2” tooling versions are older than “Preview 2”) cause the wrong version of tooling to be found. The solution is to manually delete the old versions from %PROGRAMFILES%\dotnet\sdk.