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 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. And are also releasing today. You can download and get started with.NET Core 2.1, on Windows, macOS, and Linux:. (includes the runtime).NET Core 2.1 is supported by, Visual Studio for Mac and Visual Studio Code. Docker images are available at 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 on Channel9. You can see complete details of the release in the. Related instructions, known issues, and workarounds are included in the. Please report any issues you find in the comments or at 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 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:. 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, called linux-musl, to support any Linux distro that uses. All of the other runtime IDs assume. 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.

If you are new to Raspberry Pi, I suggest the. You can 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.

You can create your own global tools by looking at the. You can try the new tools experience with the 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 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.

Maintains a list of. You might also check out his tool. The following existing 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.NET Core 2.1 Incremental Build-time performance improvements Note: 2.1 in the image refers to the 2.1.300 SDK version. Note: These benchmarks were produced from projects at. We added long-running servers to the.NET Core SDK to improve the performance of common development operations. The servers are additional processes that run for longer than a single dotnet build invocation. Some of these are ports from the.NET Framework and others are new. The following SDK build servers have been added:.

VBCSCompiler. MSBuild worker processes. Razor server The primary benefit of these servers is that they skip the need to JIT compile large blocks of code on every dotnet build invocation.

They auto-terminate after a period of time. See for more information on finer control of these build servers. Runtime Performance Improvements See for an in-depth exploration of all the performance improvements in the release. Networking Performance Improvements We built a new from-the-ground-up called to improve networking performance. It’s a C# implementation of based on. SocketsHttpHandler is now the default implementation for HttpClient. The biggest win of SocketsHttpHandler is performance.

It is a lot faster than the existing implementation. It also eliminates platform-specific dependencies and enables consistent behavior across operating systems. See the for instructions on how to enable the older networking stack. Span, Memory, and friends We are entering a new era of memory-efficient and high-performance computing with.NET, with the introduction of and related types. Today, if you want to pass the first 1000 elements of a 10,000 element array, you need to make a copy of those 1000 elements and pass that copy to your caller. That operation is expensive in both time and space. The new Span type enables you to provide a virtual view of that array without the time or space cost.

Span is a struct, which means that you can enable complex pipelines of parsing or other computation without allocating. We are using this new type extensively in for this reason.

Gives a great introduction in his. Stephen Toub goes into even more detail in. In the most simple use case, you can cast an array to a Span, as follows. You can a, as follows. This code produces the following output. Ints length: 100 spanInts length: 100 slicedInts length: 2 slicedInts contents 42 43 slicedInts contents 21300 43 Brotli Compression is a general-purpose lossless compression algorithm that compresses data comparable to the best currently available general-purpose compression methods. It is similar in speed to deflate but offers more dense compression.

The specification of the Brotli Compressed Data Format is defined in. The Brotli encoding is supported by most web browsers, major web servers, and some CDNs (Content Delivery Networks).

The.NET Core Brotli implementation is based around the c code provided by Google at. Thanks, Google!

Has been added to.NET Core 2.1. Operations may be completed using either the stream-based or the high-performance span-based / classes. You can see it used in the following example. This code produces the following output: Request URL: Initial content length: 2244 Compressed content length: 727 Decompressed content length: 2244 Compression ratio: 67.6% First 10 lines of decompressed content #.NET Core Home The dotnet/core repository is a good starting point for.NET Core. The latest major release is.NET Core 2.1(release-notes/2.1/2.1.0.md). The latest patch updates are listed in.NET Core release notes(release-notes/README.md) ## Download the latest.NET Core SDK.NET Core 2.1 SDK(release-notes/download-archives/2.1.0-download.md) New Cryptography APIs The following enhancements have been made to.NET Core cryptography APIs:. New SignedCms APIs — is now available in the package.

The.NET Core implementation is available to all.NET Core platforms and has parity with the class from.NET Framework. New X509Certificate.GetCertHash overload for SHA-2 — New overloads for and accept a hash algorithm identifier to enable callers to get certificate thumbprint values using algorithms other than SHA-1. New cryptography APIs — Span-based APIs are available for hashing, HMAC, (cryptographic) random number generation, asymmetric signature generation, asymmetric signature processing, and RSA encryption.

Release 2.1 For Mac Free

Rfc2898DeriveBytes performance improvements — The implementation of (PBKDF2) is about 15% faster, based on using. Users who benchmarked an iteration count for an amount of server time may want to update iteration count accordingly. Added CryptographicOperations class — takes a fixed amount of time to return for any two inputs of the same length, making it suitable for use in cryptographic verification to avoid contributing to timing side-channel information. Is a memory clearing routine that cannot be optimized away via a write-without-subsequent-read optimization.

Added static RandomNumberGenerator.Fill — The static will fill a Span with random values using the system-preferred CSPRNG, and does not require the caller to manage the lifetime of an IDisposable resource. Added support for RFC 3161 cryptographic timestamps — New API to request, read, validate, and create TimestampToken values as defined.

Add Unix EnvelopedCms — The EnvelopedCms class has been added for Linux and macOS. Added ECDiffieHellman — Elliptic-Curve Diffie-Hellman (ECDH) is now available on.NET Core via the class family with the same surface area as.NET Framework 4.7. Added RSA-OAEP-SHA2 and RSA-PSS to Unix platforms — Starting with.NET Core 2.1 the instance provided by can always encrypt or decrypt with OAEP using a SHA-2 digest, as well as generate or validate signatures using RSA-PSS Windows Compatibility Pack When you port existing code from the.NET Framework to.NET Core, you can use the. It provides access to an additional 20,000 APIs, compared to what is available in.NET Core. This includes System.Drawing, EventLog, WMI, Performance Counters, and Windows Services.

See for more information. The following example demonstrates accessing the Windows registry with APIs provided by the Windows Compatibility Pack.

Tiered Compilation We’ve added a preview of a new and exciting capability to the runtime called tiered compilation. It’s a way for the runtime to more adaptively use the Just-In-Time (JIT) compiler to get better performance. The basic challenge for JIT compilers is that compilation time is part of the application’s execution time. Producing better code usually means spending more time optimizing it. But if a given piece of code only executes once or just a few times, the compiler might spend more time optimizing it than the application would spend just running an unoptimized version. With tiered compilation, the compiler first generates code as quickly as possible, with only minimal optimizations (first tier). Then, when it detects that certain methods are executed a lot, it produces a more optimized version of those methods (second tier) that are then used instead.

The second tier compilation is performed in parallel, which removes the tension between fast compile speeds and producing optimal code. This model can be more generically called. Tiered compilation is also beneficial for long-running applications, such as web servers. We’ll go into more detail in follow-on posts, but the short version is that the JIT can produce much better code than is in the pre-compiled assemblies we ship for.NET Core itself. This is mostly due to the. With tiered compilation, the JIT can use the pre-compiled code it finds for.NET Core and then JIT-compile better code for methods that get called a lot.

We’ve seen this scenario having a large impact for the tests in our performance lab. You can test tiered compilation with by setting an environment variable. COMPlusTieredCompilation='1' You can enable tiered compilation for an application by setting the TieredCompilation property, as you can see done in. SourceLink is a system that enables a source debugging experiences for binaries that you either distribute or consume. It requires producers of SourceLink information and debuggers that support it.

The Visual Studio debugger already supports SourceLink, starting with Visual Studio 2017 15.3. We have added support for generating SourceLink information in symbols, binaries, and NuGet packages in the.NET Core 2.1 RC SDK. You can start producing SourceLink information by following the example at.

You can see how it is enable in. Our goal for the project is to enable anyone building for their users with almost no effort. There are a few steps left to enable the full experience, but you can get started now. The following screenshot demonstrates debugging a NuGet package referenced by an application, with source automatically downloaded from GitHub and used by Visual Studio 2017. Self-contained application publishing dotnet publish now publishes with a serviced runtime version.

When you publish a self-contained application with the new SDK, your application will include the latest serviced runtime version known by that SDK. When you upgrade to the latest SDK, you’ll publish with the latest.NET Core runtime version. This applies for.NET Core 1.0 runtimes and later. Self-contained publishing relies on runtime versions on NuGet.org. You do not need to have the serviced runtime on your machine.

Using the.NET Core 2.0 SDK, self-contained applications are published with.NET Core 2.0.0 Runtime unless a different version is specified via the RuntimeFrameworkVersion property. With this new behavior, you’ll no longer need to set this property to select a higher runtime version for self-contained application. The easiest approach going forward is to always install and publish with the latest SDK.

Docker Docker images for.NET Core 2.1 are available at. We’ve made a few changes relative to.NET Core 2.0. We have consolidating the set of Docker Hub repositories that we use for.NET Core and ASP.NET Core.

We will use as the only repository that we publish to for.NET Core 2.1 and later releases. We added a set of environment variables to.NET Core images to make it easier to host ASP.NET Core sites at any.NET Core image layer and to enable dotnet watch in SDK container images without additional configuration. Have been moved to the repo. The samples have been updated for.NET Core 2.1. New samples have been added, including.

For more information, see.NET Core 2.1 and Compatibility.NET Core 2.1 is a highly compatible release.NET Core 2.0 applications will run on.NET Core 2.1 in absence of.NET Core 2.0 being installed. This roll-forward behavior only applies to minor releases.NET Core 1.1 will not roll-forward to 2.0, nor will.NET Core 2.0 roll-forward to 3.0.

See the for instructions on how to disable minor-version roll-forward. If you built.NET Core 2.1 applications or tools with.NET Core 2.1 preview releases, they must be rebuilt with the final.NET Core 2.1 release. Preview releases do not roll-forward to final releases. Early Snap Installer Support We have been working on bringing.NET Core to and are ready to hear what you think. Snaps, along with a few other technologies, are an emerging application installation and sandboxing technology that we think is 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.NET Core 2.1 Runtime and SDK snaps are available:. 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. Closing.NET Core 2.1 is a big step forward for the platform.

We’ve significantly improved performance, added many APIs, and added a new way of deploying tools. We’ve also added support for new Linux distros and ARM32, another CPU type. This release expands the places you can use.NET Core and makes it much more efficient everywhere. We expect.NET Core 2.1 to be available in Azure App Service later this week. You can see the progress we made with the.NET Core 2.1 interim releases:,.

Thanks again to everyone who contributed to the release. It helps a lot. I find.NET Core Tools failed to install in Fedora 27 in non-root user.

It seems.NET Core tried to access SSL configuration dir/file which requires root user. Is it a specification? Or which repository should I report the issue? $dotnet tool install -g dotnetsayn /usr/share/dotnet/sdk/2.1.300/NuGet.targets(114,5): error: Unable to load the service index for source.

Release 2.1 For Macbook

/tmp/vcudhlbh.gz4/restore.csproj /usr/share/dotnet/sdk/2.1.300/NuGet.targets(114,5): error: The SSL connection could not be established, see inner exception. /tmp/vcudhlbh.gz4/restore.csproj /usr/share/dotnet/sdk/2.1.300/NuGet.targets(114,5): error: error:2006D002:BIO routines:BIOnewfile:system lib /tmp/vcudhlbh.gz4/restore.csproj. Those build time improvements make me salivate. Do on-prem TFS 2017 build agents need to be updated to compile.NET Core 2.1 projects? Also, would TFS 2015 build agents work with any.NET Core/Standard compilation? Holding off on.NET Core until I can get that cleared up.

Release 2.1 For Mac Pro

I’m in a holding pattern until I can get the following figured out. Worried that upgrading TFS 2015 to TFS 2017 will mess up my build/release agent settings/build steps/release steps/configurations. As said above, if I stick to TFS 2015 I’m worried that the TFS 2015 build agents will not be able to compile.NET Core solutions. Does this mean we can use 2.1 with VS not before VS 2017 15.8 will release? With „use“ i mean „having no VS templates, Tooling, etc.

Ofc i can just install the 2.1.300 SDK „manually“ and adapt the.csproj file like shiwn in the mentioned article. But without bringing the SDK via the VS workload, we have wether templates, nor am i sure, if i can change the target framework via properties window. I find it somewhat strange to release an SDK while VS users have to wait until they also can propely used it.

Why not release both together? We build a large financial business solution today using.net core 2.1 and need to keep it alive for 7+ years to meet government required regulations. What is the long term path over the 7+ years for this solution? A forced upgrade due to.net core 2.1 end of life mid-way through the required lifespan of the business solution costs significant money.

Our steering committee would be skeptical of development tools/platform with a forced upgrade and the required full system retesting at a future date. We’d do one or two major upgrades during the solution’s lifespan due to business functionality needs but not for a non-business need fixed date in the future. If we start a new project today and complete in 1 year, that leaves 2 years or less time until a core part of the development platform is unsupported – and a much shorter time duration until a forced upgrade.

Until.NET Core 2.0, I can create projects on.NET Core 2.0 and still compile and publish legacy projects running in.NET Framework 4.5.2 (because they use EntityFramework 6). There’s no problem in that. When I installed.NET Core 2.1 SDK, it is overwriting the 4.5.2 framework project’s compilation symbols from “NET452” to “NETFRAMEWORK;NET452” and then it is publishing the project.

But when I try to run the published project on the IIS server, it is not working. I have installed the Windows Server Hosting for.NET 2.1.0 in the server but it doesn’t seem to resolve the issue. When I uninstalled the.NET Core 2.1 SDK, it works fine.

I don’t know what change I must make in the 4.5.2 project to get it working with the 2.1 SDK. Please advice. For now I can’t upgrade the.NET Framework 4.5.2 projects to.NET Core because the entire EntityFramework 6 related sections needs to be rewritten which is a major issue.