May 30th, 2018
0 reactions

Announcing .NET Core 2.1

Program Manager

We’re excited to announce the release of .NET Core 2.1. It includes improvements to performance, to the runtime and tools. It also includes a new way to deploy tools as NuGet packages. We’ve added a new primitive type called Span<T> that operates on data without allocations. There are many other new APIs, focused on cryptography, compression, and Windows compatibility. It is the first release to support Alpine Linux and ARM32 chips. You can start updating existing projects to target .NET Core 2.1 today. The release is compatible with .NET Core 2.0, making updating easy.

ASP.NET Core 2.1 and Entity Framework Core 2.1 are also releasing today.

You can download and get started with .NET Core 2.1, on Windows, macOS, and Linux:

.NET Core 2.1 is supported by Visual Studio 15.7, Visual Studio for Mac and Visual Studio Code.

Docker images are available at microsoft/dotnet for .NET Core and ASP.NET Core.

The Build 2018 conference was earlier this month. We had several in-depth presentations on .NET Core. Check out Build 2018 sessions for .NET on Channel9.

You can see complete details of the release in the .NET Core 2.1 release notes. Related instructions, known issues, and workarounds are included in the releases notes. Please report any issues you find in the comments or at dotnet/core #1614

Thanks for everyone that contributed to .NET Core 2.1. You’ve helped make .NET Core a better product!

Long-term Support

.NET Core 2.1 will be a long-term support (LTS) release. This means that it is supported for three years. We recommend that you make .NET Core 2.1 your new standard for .NET Core development.

We intend to ship a small number of significant updates in the next 2-3 months and then officially call .NET Core 2.1 an LTS release. After that, updates will be targeted on security, reliability, and adding platform support (for example, Ubuntu 18.10). We recommend that you start adopting .NET Core 2.1 now. For applications in active development, there is no reason to hold off deploying .NET Core 2.1 into production. For applications that will not be actively developed after deployment, we recommend waiting to deploy until .NET Core 2.1 has been declared as LTS.

There are a few reasons to move to .NET Core 2.1:

  • Long-term support.
  • Superior performance and quality.
  • New platform support, such as: Ubuntu 18.04, Alpine, ARM32.
  • Much easier to manage .NET Core and ASP.NET Core versions in project files and with self-contained application publishing.

We had many requests to make .NET Core 2.0 an LTS release. In fact, that was our original plan. We opted to wait until we had resolved various challenges managing platform dependencies (the last point above). Platform dependency management was a significant problem with .NET Core 1.0 and has gotten progressively better with each release. For example, you will notice that the ASP.NET Core package references no longer include a version number with .NET Core 2.1.

Platform Support

.NET Core 2.1 is supported on the following operating systems:

  • Windows Client: 7, 8.1, 10 (1607+)
  • Windows Server: 2008 R2 SP1+
  • macOS: 10.12+
  • RHEL: 6+
  • Fedora: 26+
  • Ubuntu: 14.04+
  • Debian: 8+
  • SLES: 12+
  • openSUSE: 42.3+
  • Alpine: 3.7+

Note: The runtime ID for Alpine was previously alpine-3.6. There is now a more generic runtime ID for Alpine and similar distros, called linux-musl, to support any Linux distro that uses musl libc. All of the other runtime IDs assume glibc.

Chip support follows:

  • x64 on Windows, macOS, and Linux
  • x86 on Windows
  • ARM32 on Linux (Ubuntu 18.04+, Debian 9+)

Note: .NET Core 2.1 is supported on Raspberry Pi 2+. It isn’t supported on the Pi Zero or other devices that use an ARMv6 chip. .NET Core requires ARMv7 or ARMv8 chips, like the ARM Cortex-A53.

If you are new to Raspberry Pi, I suggest the awesome Pi resources at AdaFruit. You can buy a Pi there, too.

Major thanks to Samsung and Qualcomm for investing heavily on .NET Core ARM32 and ARM64 implementations. Please thank them, too! These contributions speak to the value of open-source.

.NET Core Tools

.NET Core now has a new deployment and extensibility mechanism for tools. This new experience is very similar to and was inspired by NPM global tools. You can create your own global tools by looking at the dotnetsay tools sample.

You can try the new tools experience with the dotnetsay tool with the following commands:

dotnet tool install -g dotnetsay
dotnetsay

.NET Core tools are .NET Core console apps that are packaged and acquired as NuGet packages. By default, these tools are framework-dependent applications and include all of their NuGet dependencies. This means that .NET Core tools run on all .NET Core supported operating system and chip architecture by default, with one set of binaries. By default, the dotnet tool install command looks for tools on NuGet.org. You can use your own NuGet feeds instead.

At present, .NET Core Tools support two installation models:

  • Global install, which requires the -g or –global parameter to install. Globally installed tools are copied to a specific location in your user profile that has been added to the path. They can be invoked directly, enabling the experience you see above, with direct use of “dotnetsay”.
  • Ad-hoc install, which requires the –tool-path parameter to install. Ad-hoc installed tools are copied to a location of your choosing, wherever –tool-path points to. They can be invoked via full path or you can add add the –tool-path location to your path, enabling a similar but custom configuration of global install.

Installation of tools without the -g or –tool-path parameters isn’t yet supported. We’re working on various forms of local tools installation, at which point you’ll be able to install tools without those parameters.

We expect a whole new ecosystem of tools to establish itself for .NET. @natemcmaster maintains a list of dotnet tools. You might also check out his dotnet-serve tool.

The following existing DotNetCliReferenceTool tools have been converted to in-box tools.

  • dotnet watch
  • dotnet dev-certs
  • dotnet user-secrets
  • dotnet sql-cache
  • dotnet ef

Remove project references to these tools when you upgrade to .NET Core 2.1.

Build Performance Improvements

Improving the performance of the .NET Core build was perhaps the biggest focus of the release. It is greatly improved in .NET Core 2.1, particularly for incremental builds. These improvements apply to both dotnet build on the command line and to builds in Visual Studio.

The following image shows the improvements that we’ve made, compared to .NET Core 2.0. We focused on large projects, as you can see from the image.