微軟正式發布.NET Core 2.1

06-04

微軟正式發布.NET Core 2.1

來自專欄微軟資訊

張善友 | dotNET跨平台

這次更新包括對性能的改進，對運行時和工具的改進。還包含一種以 NuGet 包的形式部署工具的新方法。我們添加了一個名為 Span<T> 的新基元類型，它可以在沒有內存分配的情況下對數據進行操作。還有許多其他新的 API，專註於密碼學，壓縮和 Windows 兼容性。它是第一個支持 Alpine Linux 和 ARM32 晶元的版本。您今天就可以開始將現有項目更新至 .NET Core 2.1 了。該版本與 .NET Core 2.0 兼容，更新會變得很簡單。

.NET Core 2.1 具有更快的構建性能，更快的內部工程系統並改進了與.NET框架之間的兼容性。根據Microsoft的初步基準，所有的.NET Core項目在2.1版本中都會有更快的構建時間，越大的項目獲益越明顯。

2.1版本推出一種實現框架兼容性的方法，稱為「小版本前滾（minor-version roll-forward）」，這樣就不需要再將應用程序和其運行環境相匹配了。這意味著Core 2.1的應用程序在之後的小版本（如2.2、2.3等等）將不需要進行修改就可以直接運行。這些新增特性對於獨立應用程序（譯註：Self-contained apps是.NET Core中的一種應用類型）來說是一種改進，通過使用dotnet publish命令能夠準確無誤地將這些應用程序進行打包。在2.1版本中，打包後的包將默認包含最新的補丁運行環境。

Long-term Support 長期支持

.NET Core 2.1 將是一個長期支持（LTS）版本。這意味著它會支持三年。我們建議您將 .NET Core 2.1 作為 .NET Core 開發的新標準。

我們打算在未來 2-3 個月內發布少量重要更新，然後正式將 .NET Core 2.1 作為 LTS 發布。之後，更新將針對安全性、可靠性以及添加平台支持（例如 Ubuntu 18.10）。我們建議您現在開始採用 .NET Core 2.1。對於處於活躍開發狀態的應用程序，沒有理由推遲將 .NET Core 2.1 部署到生產環境中。對於不活躍開發狀態的應用程序，我們建議您等待部署，直到將 .NET Core 2.1 聲明為 LTS。

有以下幾個原因升級到 .NET Core 2.1：

長期支持（LTS）。
卓越的性能和質量。
新的平台支持，例如：Ubuntu 18.04，Alpine，ARM32。
更容易的在項目文件中管理平台依賴關係和自包含應用程序發布。

我們收到很多希望將 .NET Core 2.0 作為 LTS 版本的請求。事實上，那是我們原來的計劃。我們選擇等待，直到我們解決了管理平台依賴性的各種挑戰（上面的最後一點）。平台依賴管理是 .NET Core 1.0 中的一個重要問題，並且隨著每個版本的逐步改進。例如，您會注意到 http://ASP.NET Core 軟體包引用不再包含 .NET Core 2.1 的版本號。

首次引入Global Tools

Global Tools是.NET Core 2.1預覽版中其中一個初次出現的特性。Global Tools提供了一種方法，讓開發人員編寫的.NET Core應用可以打包成NuGet包交付。如果.NET Core運行在目標平台上，那麼一個恰當打包的Global Tool就可以在那上面運行。JavaScript開發人員可能會發現一件有趣的事，就是這個工具直接借鑒了NPM Global Tools。最終，.NET Core Global Tools將支持安裝到用戶的本地目錄。

http://ASP.NET Core 2.1對GDPR的支持

歐盟的《通用數據保護條例》（General Data Protection Regulation，以下簡稱 GDPR）已經於 2018 年 5 月 25 日正式施行。GDPR 涵蓋了包括數據泄露發生後 72 小時內向監管機構通報的要求，以及提前告知用戶數據用途的要求等等。GDPR 允許監管機構對違反規定的公司處罰高達其全球收入的 4％的罰金。如果亞馬遜受到懲罰，罰款將為 70 億美元。然而有趣的是，由於像亞馬遜這樣的公司收入巨大，利潤卻相對較低，因此 4％的罰款可能會花掉他們兩年的利潤。如果歐盟居民提交了數據訪問請求，公司有 30 天的時間作出響應。假設一家公司收到了這樣的請求，但它們仍不完全符合 GDPR 標準，並且無法回應，那麼該居民可以向當地監管機構提出投訴。GDPR 要求監管機構採取措施來執行法律。就算不是 4% 的罰款，但他們也不能對投訴坐視不理。「如果監管機構在第一個月收到 10000 個投訴，他們就有麻煩了。

GDPR 只適用於歐盟境內和歐盟居民，但由於許多公司在歐洲開展業務，美國科技行業正在手忙腳亂地整改。儘管可以預見在 GDPR 的實施初期一定會出現問題，但這一規定標誌著全球數據處理方式的巨變。希望隨著公司和監管機構逐漸走上正軌，經 GDPR 所加強的隱私保護也將成為常態。.NET Core 2.1版本有GDPR特性，具體參見《在 http://ASP.NET Core 歐洲常規數據保護法規 (GDPR) 支持》 https://docs.microsoft.com/zh-cn/aspnet/core/security/gdpr?view=aspnetcore-2.1 ，這裡還有一篇相關博客： GDPR Support with http://ASP.NET Core 2.1 https://csharp.christiannagel.com/2018/05/24/gdpr/

Windows Compatibility Pack

將現有代碼從 .NET Framework 移植到 .NET Core 時，可以使用 Windows Compatibility Pack。它提供了額外的 20,000 個API，與 .NET Core 中可用的 API 相比。這包括System.Drawing，EventLog，WMI，性能計數器和 Windows 服務。使用.NET Framework 也有必要升級到.NET Core上享受.NETCore的高性能以及雲服務的便利。

最後給大家推薦一個楊中科老師周六帶來的微服務課程，本次直播課程的盈利將會全部捐獻給.NetCore 微服務相關開源社區。我在ocelot的上看到了楊老師提的issue： https://github.com/ThreeMammals/Ocelot/issues/375 ，不過ocelot的英國哥們還沒有回復，ocelot項目雖然有兩年多了，大家都是業餘時間在維護，彼此把項目中特性貢獻出來。一直沒有考慮過社區捐贈的事情。

Announcing .NET Core 2.1

StartHTML:000000269

EndHTML:000041681

StartFragment:000008726

EndFragment:000041614

StartSelection:000008726

EndSelection:000041610

SourceURL:https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1/?from=timeline&isappinstalled=0

<br> window._wpemojiSettings = {"baseUrl":"https://http://s.w.org/images/core/emoji/2.3/72x72/","ext":".png","svgUrl":"https://http://s.w.org/images/core/emoji/2.3/svg/","svgExt":".svg","source":{"concatemoji":"https://http://blogs.msdn.microsoft.com/dotnet/wp-includes/js/wp-

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 SDK (includes the runtime)
.NET Core 2.1 Runtime

.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 http://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 http://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 only support global install and require the -g argument to be installed. We』re working on various forms of local install, too, and plan to deliver that in a subsequent release.

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.

.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 mikeharder/dotnet-cli-perf.

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 release notes for more information on finer control of these build servers.

Runtime Performance Improvements

See Performance Improvements in .NET Core 2.1 for an in-depth exploration of all the performance improvements in the release.

Networking Performance Improvements

We built a new from-the-ground-up HttpClientHandler called SocketsHttpHandler to improve networking performance. It』s a C# implementation of HttpClient based on .NET sockets and Span<T>.

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 .NET Core 2.1 release notes for instructions on how to enable the older networking stack.

Span<T>, Memory<T>, and friends

We are entering a new era of memory-efficient and high-performance computing with .NET, with the introduction of Span<T> 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<T> type enables you to provide a virtual view of that array without the time or space cost. Span<T> 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 corefx for this reason.

Jared Parsons gives a great introduction in his Channel 9 video C# 7.2: Understanding Span. Stephen Toub goes into even more detail in C# – All About Span: Exploring a New .NET Mainstay.

In the most simple use case, you can cast an array to a Span<T>, as follows.

You can Slice a Span<T>, as follows.

This code produces the following output:

ints length: 100

spanInts length: 100

slicedInts length: 2

slicedInts contents

21300

Brotli Compression

Brotli 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 RFC 7932. 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 google/brotli. Thanks, Google!

Brotli support has been added to .NET Core 2.1. Operations may be completed using either the stream-based BrotliStream or the high-performance span-based BrotliEncoder/BrotliDecoder classes. You can see it used in the following example.

This code produces the following output:

Request URL: https://raw.githubusercontent.com/dotnet/core/master/README.md

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 — System.Security.Cryptography.Pkcs.SignedCms is now available in the System.Security.Cryptography.Pkcspackage. The .NET Core implementation is available to all .NET Core platforms and has parity with the class from .NET Framework. See: dotnet/corefx #14197.
New X509Certificate.GetCertHash overload for SHA-2 — New overloads for X509Certificate.GetCertHash and X509Certificate.GetCertHashString accept a hash algorithm identifier to enable callers to get certificate thumbprint values using algorithms other than SHA-1. dotnet/corefx #16493.
New Span<T>-based cryptography APIs — Span-based APIs are available for hashing, HMAC, (cryptographic) random number generation, asymmetric signature generation, asymmetric signature processing, and RSA encryption.
Rfc2898DeriveBytes performance improvements — The implementation of Rfc2898DeriveBytes (PBKDF2) is about 15% faster, based on using Span<T>-based. Users who benchmarked an iteration count for an amount of server time may want to update iteration count accordingly.
Added CryptographicOperations class — CryptographicOperations.FixedTimeEquals 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. CryptographicOperations.ZeroMemory is a memory clearing routine that cannot be optimized away via a write-without-subsequent-read optimization.
Added static RandomNumberGenerator.Fill — The static RandomNumberGenerator.Fill 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 by RFC 3161.
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 ECDiffieHellman 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 RSA.Create() 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 Windows Compatibility Pack. 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 Announcing the Windows Compatibility Pack for .NET Core 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 Adaptive optimization.

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 fragile binary interface problem. 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:

COMPlus_TieredCompilation="1"

You can enable tiered compilation for an application by setting the TieredCompilation property, as you can see done in this project.

SourceLink

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 dotnet/sourcelink. You can see how it is enable in this project.

Our goal for the project is to enable anyone building NuGet libraries to provide source debugging 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 self-contained applications 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 microsoft/dotnet on Docker Hub. 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 microsoft/dotnet 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 http://ASP.NET Core sites at any .NET Core image layer and to enable dotnet watch in SDK container images without additional configuration.

.NET Core Docker Samples have been moved to the dotnet/dotnet-docker repo. The samples have been updated for .NET Core 2.1. New samples have been added, including Hosting ASP.NET Core Images with Docker over HTTPS.

For more information, see .NET Core 2.1 Docker Image Updates.

.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 .NET Core 2.1 release notes 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 Snap 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: RC1, Preview 2, Preview 1. Thanks again to everyone who contributed to the release. It helps a lot.