Today, we are announcing .NET Core 3.0 Preview 6. It includes updates for compiling assemblies for improved startup, optimizing applications for size with linker and EventPipe improvements. We’ve also released new Docker images for Alpine on ARM64.
今天，我们宣布.NET Core 3.0 Preview 6 。 它包括编译程序集的更新，以改进启动，通过链接程序和EventPipe的改进来优化应用程序的大小。 我们还在ARM64上为Alpine发布了新的Docker映像。
Download .NET Core 3.0 Preview 6 right now on Windows, macOS and Linux.
立即在Windows，macOS和Linux上下载.NET Core 3.0 Preview 6 。
Release notes have been published at dotnet/core. An API diff between Preview 5 and 6 is also available.
发行说明已发布在dotnet / core上 。 还提供了预览5和预览6之间的API差异 。
ASP.NET Core and EF Core are also releasing updates today.
ASP.NET Core和EF Core今天也发布更新。
If you missed it, check out the improvements we released in .NET Core 3.0 Preview 5, from last month.
如果您错过了它，请查看我们上个月在.NET Core 3.0 Preview 5中发布的改进。
WPF和Windows窗体更新 (WPF and Windows Forms update)
The WPF team has now completed publishing most of the WPF codebase to GitHub. In fact, they just published source for fifteen assemblies. For anyone familiar with WPF, the assembly names should be very familiar.
WPF团队现在已经完成了将大部分WPF代码库发布到GitHub的工作 。 实际上，他们只是发布了十五个程序集的源代码 。 对于熟悉WPF的任何人，程序集名称都应该非常熟悉。
In some cases, tests are still on the backlog to get published at or before 3.0 GA. That said, the presence of all of this code should enable the WPF community to fully participate in making changes across WPF. It is obvious from reading some of the GitHub issues that the community has its own backlog that it has been waiting to realize. Dark theme, maybe?
在某些情况下，测试仍在积压中以在3.0 GA或之前发布。 也就是说，所有这些代码的存在应该使WPF社区能够完全参与WPF的更改。 从阅读GitHub的一些问题可以明显看出，社区有自己的积压等待实现。 黑暗的主题，也许吗？
高山Docker映像 (Alpine Docker images)
Docker images are now available for both .NET Core and ASP.NET Core on ARM64. They were previously only available for x64.
Docker映像现在可用于ARM64上的.NET Core和ASP.NET Core。 它们以前仅适用于x64。
The following images can be used in a Dockerfile, or with docker pull, as demonstrated below:
可以在Dockerfile或Dockerfile docker pull使用以下图像，如下所示：
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
事件管道的改进 (Event Pipe improvements)
Event Pipe now supports multiple sessions. This means that you can consume events with EventListener in-proc and simultaneously have out-of-process event pipe clients.
事件管道现在支持多个会话。 这意味着您可以使用EventListener进程内消费事件，同时拥有进程外事件管道客户端。
New Perf Counters added:
添加了新的Perf计数器：
- % Time in GC ％GC时间
- Gen 0 Heap Size Gen 0堆大小
- Gen 1 Heap Size 第一代堆大小
- Gen 2 Heap Size 第2代堆大小
- LOH Heap Size LOH堆大小
- Allocation Rate 分配率
- Number of assemblies loaded 装配件数
- Number of ThreadPool Threads 线程池线程数
- Monitor Lock Contention Rate 监视锁争用率
- ThreadPool Work Items Queue ThreadPool工作项队列
- ThreadPool Completed Work Items Rate ThreadPool完成的工作项比率
Profiler attach is now implemented using the same Event Pipe infrastructure.
现在使用相同的事件管道基础结构来实现Profiler附加。
See Playing with counters from David Fowler to get an idea of what you can do with event pipe to perform your own performance investigations or just monitor application status.
请参阅David Fowler的“ 与计数器一起玩”，以了解如何使用事件管道执行自己的性能调查或仅监视应用程序状态。
See dotnet-counters to install the dotnet-counters tool.
请参阅dotnet-counters以安装dotnet-counters工具。
使用ReadyToRun图像优化.NET Core应用 (Optimize your .NET Core apps with ReadyToRun images)
You can improve the startup time of your .NET Core application by compiling your application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation.
通过将应用程序程序集编译为ReadyToRun(R2R)格式，可以缩短.NET Core应用程序的启动时间。 R2R是一种提前(AOT)编译的形式。
R2R binaries improve startup performance by reducing the amount of work the JIT needs to do as your application is loading. The binaries contain similar native code as what the JIT would produce, giving the JIT a bit of a vacation when performance matters most (at startup). R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code, to improve startup.
R2R二进制文件通过减少应用程序加载时JIT需要完成的工作量来提高启动性能。 二进制文件包含与JIT产生的代码相似的本机代码，从而在性能最重要时(启动时)使JIT有了一些假期。 R2R二进制文件较大，因为它们既包含中间语言(IL)代码(某些情况下仍然需要此代码)，也包含相同代码的本机版本，以改善启动。
R2R is supported with .NET Core 3.0. It cannot be used with earlier versions of .NET Core.
.NET Core 3.0支持R2R。 它不能与.NET Core的早期版本一起使用。
样本性能数据 (Sample performance numbers)
The following are performance numbers collected using a sample WPF application. The application was published as self-contained and did not use the assembly linker (covered later this post).
以下是使用示例WPF应用程序收集的性能数字。 该应用程序被发布为自包含的，并且未使用程序集链接器(在本文后面介绍)。
IL-only Application:
仅IL的应用程序：
- Startup time: 1.9 seconds 启动时间：1.9秒
- Memory usage: 69.1 MB 内存使用量：69.1 MB
- Application size: 150 MB 应用大小：150 MB
With ReadyToRun images:
使用ReadyToRun图像：
- Startup time: 1.3 seconds. 启动时间：1.3秒。
- Memory usage: 55.7 MB 内存使用量：55.7 MB
- Application size: 156 MB 应用大小：156 MB
ReadyToRun映像，说明 (ReadyToRun images, explained)
You can R2R compile both libraries and application binaries. At present, libraries can only be R2R compiled as part of an application, not for delivery as a NuGet package. We’d like more feedback on whether that scenario is important.
您可以R2R编译库和应用程序二进制文件。 目前，只能将R2R库作为应用程序的一部分进行编译，而不能作为NuGet包进行交付。 我们希望获得更多有关该方案是否重要的反馈。
AOT compiling assemblies has been available as a concept with .NET for a long time, going back to the .NET Framework and NGEN. NGEN has a key drawback, which is that compilation must be done on client machines, using the NGEN tool. It isn’t possible to generate NGEN images as part of your application build.
AOT编译程序集作为.NET的概念已经很长时间了，可以追溯到.NET Framework和NGEN 。 NGEN有一个关键缺点，那就是必须使用NGEN工具在客户端计算机上进行编译。 作为应用程序构建的一部分，不可能生成NGEN映像。
Enter .NET Core. It comes with crossgen, which produces native images in a newer format called ReadyToRun. The name describes its primary value proposition, which is that these native images can be built as part of your build and are “ready to run” without any additional work on client machines. That’s a major improvement, and also an important win for climate change.
输入.NET Core。 它带有crossgen ，可生成称为ReadyToRun的较新格式的本机图像。 该名称描述了其主要价值主张，即这些本机映像可以作为您的构建的一部分进行构建，并且“准备好运行”而无需在客户端计算机上进行任何其他工作。 这是一项重大进步，也是应对气候变化的重要胜利。
In terms of compatibility, ReadyToRun images are similar to IL assemblies, with some key differences.
在兼容性方面，ReadyToRun映像类似于IL程序集，但有一些关键区别。
IL assemblies contain just IL code. They can run on any runtime that supports the given target framework for that assembly. For example a
netstandard2.0assembly can run on .NET Framework 4.6+ and .NET Core 2.0+, on any supported operating system (Windows, macOS, Linux) and architecture (Intel, ARM, 32-bit, 64-bit).IL程序集仅包含IL代码 。 它们可以在支持该程序集给定目标框架的任何运行时上运行。 例如，
netstandard2.0程序集可以在任何受支持的操作系统(Windows，macOS，Linux)和体系结构(英特尔，ARM，32位，64位)上的.NET Framework 4.6+和.NET Core 2.0+上运行。R2R assemblies contain IL and native code. They are compiled for a specific minimum .NET Core runtime version and runtime environment (RID). For example, a
netstandard2.0assembly might be R2R compiled for .NET Core 3.0 and Linux x64. It will only be usable in that or a compatible configuration (like .NET Core 3.1 or .NET Core 5.0, on Linux x64), because it contains native code that is only usable in that runtime environment.R2R程序集包含IL和本机代码。 它们针对特定的最低.NET Core运行时版本和运行时环境(RID)进行编译。 例如，一个
netstandard2.0程序集可能是为.NET Core 3.0和Linux x64编译的R2R。 它仅在该配置或兼容配置中可用(例如Linux x64上的.NET Core 3.1或.NET Core 5.0)，因为它包含仅在该运行时环境中可用的本机代码。
使用说明 (Instructions)
The ReadyToRun compilation is a publish-only, opt-in feature. We’ve released a preview version of it with .NET Core 3.0 Preview 5.
ReadyToRun编译是仅发布的选择功能。 我们已经发布了.NET Core 3.0 Preview 5的预览版。
To enable the ReadyToRun compilation, you have to:
要启用ReadyToRun编译，您必须：
Set the
PublishReadyToRunproperty totrue.将
PublishReadyToRun属性设置为true。Publish using an explicit
RuntimeIdentifier.使用显式
RuntimeIdentifier发布。
Note: When the application assemblies get compiled, the native code produced is platform and architecture specific (which is why you have to specify a valid RuntimeIdentifier when publishing).
注意：编译应用程序程序集时，生成的本机代码特定于平台和体系结构(这就是发布时必须指定有效的RuntimeIdentifier的原因)。
Here’s an example:
这是一个例子：
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>
</Project>And publish using the following command:
并使用以下命令发布：
dotnet publish -r win-x64 -c ReleaseNote: The RuntimeIdentifier can also be set in the project file.
注意：也可以在项目文件中设置RuntimeIdentifier 。
Note: ReadyToRun is currently only supported for self-contained apps. It will be enabled for framework-dependent apps in a later preview.
注意：ReadyToRun当前仅受自包含应用程序支持。 在以后的预览中，将为依赖框架的应用程序启用它。
Native symbol generation can be enabled by setting the PublishReadyToRunEmitSymbols property to true in your project. You do not need to generate native symbols for debugging purposes. These symbols are only useful for profiling purposes.
可以通过在项目PublishReadyToRunEmitSymbols属性设置为true来启用本机符号生成。 您无需生成用于调试目的的本机符号。 这些符号仅对概要分析有用。
The SDK currently supports a way to exclude certain assemblies from being compiled into ReadyToRun images. This could be useful for cases when certain assemblies do not really need to be optimized for performance. This can help reduce the size of the application. It could also be a useful workaround for cases where the ReadyToRun compiler fails to compile a certain assembly. Exclusion is done using the PublishReadyToRunExclude item group. Example:
该SDK当前支持一种将某些程序集从编译成ReadyToRun映像中排除的方法。 对于某些组件确实不需要针对性能进行优化的情况，这可能很有用。 这可以帮助减小应用程序的大小。 对于ReadyToRun编译器无法编译某个程序集的情况，这也可能是一个有用的解决方法。 排除是使用PublishReadyToRunExclude项组完成的。 例：
<ItemGroup>
<PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" />
</ItemGroup>跨平台/架构编译 (Cross platform/architecture compilations)
The ReadyToRun compiler doesn’t currently support cross-targeting. You need to compile on a given target. For example, if you want R2R images for Windows x64, you need to run the publish command on that environment.
ReadyToRun编译器当前不支持交叉目标。 您需要在给定的目标上进行编译。 例如，如果您想要Windows x64的R2R映像，则需要在该环境上运行publish命令。
Exceptions to this:
例外情况：
- Windows x64 can be used to compiles Windows ARM32, ARM64, and x86 images. Windows x64可用于编译Windows ARM32，ARM64和x86映像。
- Windows x86 can be used to compile Windows ARM32 images. Windows x86可用于编译Windows ARM32映像。
- Linux x64 can be used to compile Linux ARM32 and ARM64 images. Linux x64可用于编译Linux ARM32和ARM64映像。
装配链接 (Assembly linking)
The .NET core 3.0 SDK comes with a tool that can reduce the size of apps by analyzing IL and trimming unused assemblies.
.NET core 3.0 SDK附带了一个工具，该工具可以通过分析IL和修剪未使用的程序集来减小应用程序的大小。
With .NET Core, it has always been possible to publish self-contained apps that include everything needed to run your code, without requiring .NET to be installed on the deployment target. In some cases, the app only requires a small subset of the framework to function and could potentially be made much smaller by including only the used libraries.
借助.NET Core，始终可以发布包含运行代码所需的一切的自包含应用程序，而无需在部署目标上安装.NET。 在某些情况下，该应用仅需要框架的一小部分即可运行，并且可能仅包含所使用的库就可以变得更小。
We use the IL linker to scan the IL of your application to detect which code is actually required, and then trim unused framework libraries. This can significantly reduce the size of some apps. Typically, small tool-like console apps benefit the most as they tend to use fairly small subsets of the framework and are usually more amenable to trimming.
我们使用IL链接器扫描应用程序的IL，以检测实际需要哪些代码，然后修剪未使用的框架库。 这可以显着减小某些应用程序的大小。 通常，类似小型工具的控制台应用程序受益最大，因为它们倾向于使用框架的较小子集，并且通常更易于调整。
To use this tool, set PublishTrimmed=true in your project and publish a self-contained app:
要使用此工具，请在项目中设置PublishTrimmed=true并发布一个独立的应用程序：
dotnet publish -r <rid> -c ReleaseThe publish output will include a subset of the framework libraries, depending on what the application code calls. For a helloworld app, the linker reduces the size from ~68MB to ~28MB.
根据应用程序代码的调用，发布输出将包括框架库的子集。 对于helloworld应用程序，链接器将大小从〜68MB减小到〜28MB。
Applications or frameworks (including ASP.NET Core and WPF) that use reflection or related dynamic features will often break when trimmed, because the linker doesn’t know about this dynamic behavior and usually can’t determine which framework types will be required for reflection at run time. To trim such apps, you need to tell the linker about any types needed by reflection in your code, and in any packages or frameworks that you depend on. Be sure to test your apps after trimming.
修剪后使用反射或相关动态功能的应用程序或框架(包括ASP.NET Core和WPF)通常会中断，因为链接器不了解这种动态行为，并且通常无法确定反射所需的框架类型在运行时。 要修剪此类应用程序，您需要告诉链接器有关代码中以及依赖的任何包或框架中反射所需要的任何类型。 修剪后一定要测试您的应用程序。
For more information about the IL Linker, see the documentation, or visit the mono/linker repo.
有关IL Linker的更多信息，请参阅文档 ，或访问mono / linker存储库。
Note: In previous versions of .NET Core, ILLink.Tasks was shipped as an external NuGet package and provided much of the same functionality. It is no longer supported – please update to the latest 3.0 SDK and try the new experience!
注意：在.NET Core的早期版本中， ILLink.Tasks作为外部NuGet软件包提供，并提供了许多相同的功能。 不再受支持-请更新到最新的3.0 SDK并尝试新的体验！
一起使用链接器和ReadToRun (Using the Linker and ReadToRun Together)
The linker and ReadyToRun compiler can be used for the same application. In general, the linker makes your application smaller, and then the ready-to-run compiler will make it a bit larger again, but with a significant performance win. It is worth testing in various configurations to understand the impact of each option.
链接器和ReadyToRun编译器可用于同一应用程序。 通常，链接器使您的应用程序更小，然后可以运行的编译器将其再次增大一些，但在性能上有明显优势。 值得在各种配置中进行测试以了解每个选项的影响。
Note: dotnet/sdk #3257 prevents the linker and ReadyToRun from being used together for WPF and Windows Forms applications. We are working on fixing that as part of the .NET Core 3.0 release.
注意： dotnet / sdk＃3257防止将链接器和ReadyToRun一起用于WPF和Windows Forms应用程序。 我们正在努力将其修复为.NET Core 3.0版本的一部分。
本机托管示例 (Native Hosting sample)
The team recently posted a Native Hosting sample. It demonstrates a best practice approach for hosting .NET Core in a native application.
该团队最近发布了本机托管示例 。 它演示了在本机应用程序中托管.NET Core的最佳实践方法。
As part of .NET Core 3.0, we now expose general functionality to .NET Core native hosts that was previously only available to .NET Core managed applications through the officially provided .NET Core hosts. The functionality is primarily related to assembly loading. This functionality should make it easier to produce native hosts that can take advantage of the full feature set of .NET Core.
作为.NET Core 3.0的一部分，我们现在向.NET Core本机主机公开常规功能，该功能以前只能通过正式提供的.NET Core主机提供给.NET Core托管的应用程序。 该功能主要与程序集加载有关。 使用此功能应该可以更轻松地生成可以利用.NET Core完整功能集的本机主机。
HttpClient中的HTTP / 2支持 (HTTP/2 support in HttpClient)
HTTP/2 is a major revision of the HTTP protocol. Some of the notable features of HTTP/2 are support for header compression and fully multiplexed streams over the same connection. While HTTP/2 preserves HTTP’s semantics (HTTP headers, methods, etc) it is a change from HTTP/1.x in how data is framed and sent over the wire.
HTTP / 2是HTTP协议的主要修订版。 HTTP / 2的一些显着功能是支持标头压缩和同一连接上的完全多路复用的流。 尽管HTTP / 2保留了HTTP的语义(HTTP标头，方法等)，但它与HTTP / 1.x相比，是如何在帧结构和通过网络发送数据方面进行了更改。
HttpClient now add supports for making HTTP/2 requests. While the default remains HTTP/1.1, you can opt in to using HTTP/2 by setting the version on your HTTP request message.
HttpClient现在添加了对发出HTTP / 2请求的支持。 当默认设置为HTTP / 1.1时，您可以通过在HTTP请求消息上设置版本来选择使用HTTP / 2。
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
// HTTP/1.1 request
using (var response = await client.GetAsync("/"))
{
Console.WriteLine(response.Content);
}
// HTTP/2 request
using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) })
using (var response = await client.SendAsync(request))
{
Console.WriteLine(response.Content);
}Alternatively, you can default to sending HTTP/2 requests by setting the DefaultRequestVersionproperty on HttpClient.
另外，您可以通过在HttpClient上设置DefaultRequestVersion属性来默认发送HTTP / 2请求。
var client = new HttpClient()
{
BaseAddress = new Uri("https://localhost:5001"),
DefaultRequestVersion = new Version(2, 0)
};
// Defaults to HTTP/2
using (var response = await client.GetAsync("/"))
{
Console.WriteLine(response.Content);
}As a consequence of this change in framing, servers and clients need to negotiate the protocol version used. Application-Layer Protocol Negotiation (ALPN) is a TLS extension that allows the server and client negotiate the protocol version used as part of their TLS handshake. While it is possible to have prior knowledge between the server and the client on the protocol, most servers only support ALPN as the only way to establish an HTTP/2 connection. As such, HTTP/2 is negotiated by HttpClient only on a TLS connection.
由于帧更改，服务器和客户端需要协商使用的协议版本。 应用程序层协议协商(ALPN)是TLS扩展，它允许服务器和客户端协商用作其TLS握手一部分的协议版本。 尽管可能在服务器和客户端之间就协议有先验知识，但是大多数服务器仅支持将ALPN作为建立HTTP / 2连接的唯一方法。 这样，HTTP / 2仅由HttpClient在TLS连接上协商。
In development scenarios when server and client have a priori knowledge that both will speak HTTP/2 unencrypted, you may establish an HTTP/2 connection over cleartext by setting an AppContext switch or an environment variable (DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1).
在开发方案中，当服务器和客户端具有先验知识，即双方都将讲未加密的HTTP / 2时，可以通过设置AppContext开关或环境变量( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 )在明文上建立HTTP / 2连接。
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);闭幕 (Closing)
Please try out the new features. Please file issues for the bugs or any challenging experiences you find. We want the feedback! You can file feature requests, too, but they likely will need to wait to get implemented until the next release at this point.
请尝试新功能。 请提出问题或发现的错误或挑战。 我们需要反馈！ 您也可以提交功能请求，但是此时它们可能需要等待实现，直到下一个版本。
We are now getting very close to being feature complete for .NET Core 3.0, and are now transitioning the focus of the team to the quality of the release. We’ve got a few months of bug fixing and performance work ahead. We’ll appreciate your feedback as we work through that process, too.
现在，我们已经非常接近.NET Core 3.0的功能完善，并且正在将团队的重点转移到版本的质量上。 我们还有几个月的错误修复和性能工作。 我们也将在此过程中感谢您的反馈。
On that note, we will soon be switching the master branches on .NET Core repos to the next major release, likely at or shortly after the Preview 7 release (July).
关于这一点，我们将很快将.NET Core存储库上的master分支切换到下一个主要版本，可能在Preview 7版本(7月)或之后不久。
Thanks for trying out .NET Core 3.0 previews. We appreciate your help. At this point, we’re focused on getting a final release in your hands.
感谢您试用.NET Core 3.0预览版。 感谢您的帮助。 在这一点上，我们专注于掌握最终版本。
Richard Lander 理查德·兰德
PM, .NET Team
.NET团队经理
557
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
