.NET Core 2.1.0 is available for download and usage in your environment. Have a look at the Known Issues document as there are a few things to be aware of before installing. A changelist for the entire 2.1 development cycle is also available. This does not include ASP.NET Core or Entity Framework Core.
The .NET Core SDK 2.1 includes .NET Core 2.1 Runtime so downloading the runtime packages separately is not needed when installing the SDK. After installing the .NET Core SDK 2.1, running dotnet --version
will show that you’re running version 2.1.300
of the .NET Core tools.
dotnet --info
has been greatly enhanced in .NET Core 2.1 and now provides detailed information on installed .NET Core components.
Your feedback is important and appreciated. We’ve created an issue at dotnet/core #1614 for your questions and comments.
The .NET Core Docker images have been updated for this release. Look for the 2.1 images.
The .NET Core installers now support package manager updates (eg apt-get update
) functionality.
We have been working on bringing .NET Core to Snap and are ready to hear what you think. Snaps, along with a few other technologies, are an emerging application installation and sandboxing technology which we think is pretty intriguing. The Snap install works well on Debian-based systems and other distros such as Fedora are having challenges that we’re working to run down. The following steps can be used if you would like to give this a try.
sudo snap install dotnet-sdk --candidate --classic
sudo snap install dotnet-runtime-21 --candidate
Watch for future posts delving into what Snaps are about. In the meantime, we would love to hear your feedback.
dotnet tool
supports the following commands:
dotnet tool install
— installs a tooldotnet tool update
— uninstalls and reinstalls a tool, effectively updating itdotnet tool uninstall
— uninstalls a tooldotnet tool list
— lists currently installed tools--tool-path
— specifies a specific location to (un)install and list tools, per invocation--global
or -g
– specifies that a tool command should be in the global scope. No other scopes are currently supported.dotnet build
process controlYou can manually terminate the build server processes via the following command:
dotnet build-server shutdown
You can prevent worker processes from being created with the following syntax:
dotnet build -nodeReuse:false
You can use one of the following mechanisms to configure a process to use the older HttpClientHandler:
From code, use the AppContext class:
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
The AppContext switch can also be set by config file.
The same can be achieved via the environment variable DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER
. To opt out, set the value to either false
or 0
.
On Windows, you can choose to use WinHttpHandler
or SocketsHttpHandler
on a call-by-call basis. To do that, instantiate one of those types and then pass it to HttpClient when you instantiate it.
On Linux and macOS, you can only configure HttpClient
on a process-basis. On Linux, you need to deploy libcurl yourself if you want to use the old HttpClient
implementation. If you have .NET Core 2.0 working on your machine, then libcurl is already installed.
See all changes from 2.0 in the detailed API diff to help determine if any will impact existing projects built on .NET Core 2.0.