.NET 6预览版1

今天，我们很高兴提供.NET 6的第一个预览版，并分享您对新版本的期望。在过去的几个月中，我们一直在定义发行版的整体形状，包括大量的新体验和功能。 .NET 6的核心是提供从.NET 5开始的.NET统一计划的最终部分。该版本还将对.NET的所有部分进行重大改进，包括针对云，桌面和移动应用程序。 .NET 6版本将完全可用该版本的更大范围的多个预览。

.NET 6已通过Visual Studio 16.9 Preview 4和Visual Studio for Mac 8.9进行了测试。如果您想尝试.NET 6，我们建议您使用这些版本。

.NET 6将使您能够为要定位的平台以及要用于开发的操作系统构建要构建的应用程序。通过提供.NET统一愿景的其余部分，我们正在扩展您可以使用.NET进行的工作以及您可以在其中进行的工作。我们将Xamarin的一部分的Android，iOS和macOS功能集成到.NET 6中。我们还将Blazor的功能扩展到一种新型的混合客户端应用程序（将Web和本机UI结合在一起）可用于桌面和移动方案。这些新功能将在本文后面和后续预览中进行描述。

我们的统一努力为所有.NET开发人员提供了便利。如果您是桌面应用程序开发人员，那么您就有新的机会吸引新用户。如果您是移动应用程序开发人员，则在瞄准iOS和Android平台时，将受益于使用主线.NET工具和API。如果您是Web或云开发人员，则将服务公开到.NET移动应用程序并与它们共享代码将更加容易。

我们在.NET 5中开始了统一过程。对于该版本，我们选择Blazor WebAssembly作为第一个可交付的统一平台。它基于Mono运行时，使用.NET类库和.NET SDK工具。集成Xamarin时，我们将对iOS和Android使用相同的模型。有了统一的平台，新的API和性能改进将在同一天为所有开发人员使用，并适用于所有应用程序。

安装.NET SDK时，您可以开始构建用于移动平台的应用程序。这意味着您将能够输入dotnet new android，然后运行dotnet，并期望Android模拟器开始运行.NET应用。 iOS应用程序也是如此。您将在Visual Studio和Visual Studio Code中拥有类似的经验。不用担心由于支持移动工作负载，.NET SDK会变得更大。移动工作负载将是可选的。实际上，由于现有工作负载也变得可选，.NET SDK将变得越来越小。新的可选SDK工作负载体验将成为.NET 6的一部分，并将在.NET 7中完成。

我们正在利用围绕统一的机会来简化和扩展构建Xamarin Forms应用程序的经验。我们称该项目为.NET多平台应用UI。该项目将提供许多改进和功能，从而扩展台式机和移动开发人员的平台范围。

我们在.NET 6中采用了更为开放的计划过程。我们在计划.NET版本时采用主题，史诗和用户故事的分层模型，并具有优先级和类别。此模型使您可以在更大范围内查看发行版，提供有关哪些功能最重要的见解，并使其更容易找到参与和贡献的机会。

您可能会注意到，.NET 6的GitHub主题和史诗性问题已于9月开始出现。尽管我们之前已经计划了很多次产品发布，但我们从未针对GitHub问题来做到这一点。对于.NET 5，我们使用了Azure DevOps。全面了解我们计划的最佳方法是使用基于Blazor的themesof.net应用程序。

在此过程开始之初，我们没有发布任何重大消息，因为我们仍在弄清楚该过程和模型，并且还没有故事可以讲。但是，我们确实向一些人指出了我们所做的事情。我们首先在Red Hat与我们的朋友交谈，尽管他们已经在观察我们的活动并弄清楚我们在做什么。他们很高兴我们在项目开放方面迈出了下一步。接下来，我们与.NET Foundation董事会分享了我们的新开放式规划方法。开放式计划还使Microsoft的其他团队更容易查看.NET团队的下一步工作。

您在GitHub上看到的计划现在是我们工程流程的基本组成部分。我们将尽力使这些问题保持最新状态，并将问题与相关活动和文档相关联，以帮助您更好地了解项目的深度和广度。我们鼓励您参与，提出问题并提供反馈。

.NET 6将在2021年11月发布，并将作为长期支持（LTS）版本获得三年的支持。与.NET 5相比，该平台矩阵已得到显着扩展。

.NET 6的默认.NET容器映像（从Preview 1开始）基于Debian 11（“ bullseye”）。容器部分将对此进行更多讨论。

.NET多平台应用程序UI是一个现代UI工具包，它基于Xamarin并作为.NET 6统一的一部分进行扩展。我们已经收到许多人的来信，您希望在各种平台和设备上提供美好而一致的应用程序体验，并且希望在移动和桌面应用程序之间共享更多代码。您将可以定位Android，iOS，macOS和Windows。 .NET 6多平台移动和跨平台支持将基于Xamarin.Forms工具包的集成和扩展，该工具包在过去的七年中已经进行了改编，并满足了许多客户不断变化的需求。 .NET 6的主要重点领域是：应用程序性能，添加新的控件主题和更快的开发人员体验。

作为统一过程的一部分，我们认为将Xamarin.Essentials库合并到.NET Multi-platform App UI中非常有意义。除了跨平台的UI控件外，您还可以轻松使用设备功能（例如设备传感器），常用功能（例如照片和联系人）以及您定期使用的许多服务（例如身份验证和安全存储）。

.NET 6 Preview 1引入了.NET多平台应用程序UI的前两个平台：Android和iOS。 .NET 6示例移动项目和安装说明将帮助您开始构建Android和iOS应用。将来的预览版将添加对macOS和Windows桌面的支持，将C＃Hot Reload添加到现有的XAML支持中以提供更快的开发体验，并引入新的项目功能以从一个地方管理资产和特定于平台的需求。

今天使用Xamarin的开发人员将能够开始将.NET 6与Xamarin和Xamarin.Forms项目一起使用。我们将提供转换工具和迁移指南，以帮助您过渡到使用.NET 6。

此图像演示了通过dotnet从macOS终端启动的Android和iOS应用程序，分别在Android模拟器和iOS模拟器中运行。它们同样可以在物理移动硬件上运行。该应用程序包括从dotnet-runtimeinfo改编的代码，并在调试输出窗口中使用Debug.WriteLine跟踪显示结果。该应用程序通过.NET SDK在带有.NET库的Mono运行时上运行。

Blazor已成为编写.NET Web应用程序的一种非常流行的方式。我们首先在服务器上支持Blazor，然后在具有WebAssembly的浏览器中提供支持，现在我们再次对其进行扩展，以使您能够编写Blazor桌面应用程序。 Blazor桌面使您能够创建混合客户端应用程序，这些应用程序将Web和本机UI组合在本机客户端应用程序中。它主要针对希望为其用户提供丰富的客户端和脱机体验的Web开发人员。

Blazor桌面为您构建应用程序提供了很多选择。在应用程序范围的一端，您可以将Blazor和Web技术用于客户端应用程序体验的各个方面，但最外面的本机应用程序容器（如标题栏）除外。另一方面，您可以将Blazor桌面用于其他本机应用程序（例如WPF）中的目标功能，例如您已经为基于Blazor的网站实现的用户个人资料页面。两者之间的所有选择都是一样的。我们最初是为.NET应用程序构建Blazor桌面，但是出于技术原因，您不能在由另一个应用程序堆栈（例如Swift）构建的桌面应用程序中使用它。

Blazor建立在.NET多平台应用程序UI之上。它依赖于该UI堆栈来获得本机应用程序容器和本机控件（您应该使用它们）。我们正在构建Blazor，使其具有与其他桌面解决方案相同的启动和吞吐量性能。对于喜欢Blazor和Web技术的开发人员，我们认为Blazor将是构建桌面应用程序的理想选择。

上图演示了在macOS上运行的Blazor桌面应用程序。在此示例中，您可以看到整个应用程序都是使用Blazor构建的，但外部chrome除外，后者是Mac应用程序容器提供的。

上图演示了另一个在Windows上运行的Blazor桌面应用程序。在此示例中，您将看到一个带有WPF控件的WPF应用程序，以及一个能够与WPF进行交互的Blazor岛（在本例中为WPF消息框）。

快速迭代开发是任何令人愉悦且高效的开发平台的标志。我们已经开始了一个新项目，我们称之为快速内循环。该项目的第一部分是通过一组与性能相关的项目来使构建的运行速度显着提高。另一个同样重要的部分是创建新系统，使我们可以完全跳过构建，使您的代码编辑可以应用于实时过程而无需重新启动。

我们一直在关注过去几年Xamarin团队在XAML热重装方面的创新，并开始想象将热重装作为一种通用的.NET功能，不仅适用于XAML，还适用于C＃/ IL。我们正在定义一个新的热代码重载模型，我们可以为所有类型的应用程序提供该模型。至少有一部分功能可能会在运行时实现，我们承诺同时使用CoreCLR和Mono来实现。作为.NET的新标准功能，我们希望为代码更改提供一个非常快速的构建，甚至是更快的操作，以完全跳过构建过程。

Arm64仍然是我们以及整个行业的重点。我们通过.NET 5.0对Arm64性能进行了重大改进，并将继续投资于Arm64性能。对于此版本，我们将最集中于功能支持。

在Windows上，我们将添加对Windows窗体和Windows Presentation Framework（WPF）的支持，并在Preview 1中提供初始支持。这是在.NET 5附带的Windows Arm64功能的基础上。我们将继续对每个组件进行改进根据反馈进行预览。我们之前曾说过，我们计划在早期的.NET 6版本中将Windows桌面应用程序功能移植到.NET 5。尽管我还没有约会的日期，但这仍然是计划。我们的目标是今年上半年。

此图像演示了使用从dotnet-runtimeinfo改编的代码在Windows Arm64机器上运行的WPF。这与我们在.NET 5上演示的Windows Forms示例非常相似（但到目前为止尚不支持）。

在Mac上，我们将添加对Apple Silicon（Arm64）芯片（本机和仿真）的支持，并在Preview 1中提供初始支持。我们将支持控制台应用，ASP.NET Core，Mac客户端应用（Mac和Mac Catalyst）以及.NET SDK。对于.NET 5和更早的.NET Core版本，我们将依靠x64仿真。稍后将在文章中更详细地介绍Apple Silicon。

此图像使用我们的ASP.NET示例之一演示了对Apple Silicon的支持。如您所见，它在macOS上运行.NET 6.0 Arm64（Darwin是macOS，xnu是内核）。

容器是团队的日常工作，既是构建基础结构的基础，又是产品方案。 .NET性能测试也在容器中完成。我们计划多个项目来改善.NET 6中的容器。

改善容器的缩放比例，并更好地支持Windows进程隔离的容器。我们还计划了一种针对密度和总体机器性能的新型容器性能测试。

使用PGO减小容器图像的大小（稍后会详细介绍；请参阅“非常冷”的拆分）。

所有这些功能（第一个功能除外）都依赖于crossgen2，稍后将对此进行描述。这些功能大多数都不是特定于容器的，但是，我们希望在容器中使用它们。在某些情况下，例如版本气泡，容器可能是唯一默认启用功能的分发工具。容器的一个重要优点是，与更通用的.tar.gz，.deb或.msi可交付成果相比，我们可以以更自以为是的配置提供.NET。我们宁愿提供性能更高配置的容器，但缺点是它们可能无法在所有情况下都可用（例如在旧硬件上）。

每当我们启动一个新版本时，我们都会查看Linux发行版的情况，以确保我们做出最佳的基本映像版本选择。 .NET 6映像将基于Alpine 3.13（或更高版本），Debian 11（“ bullseye”）和Ubuntu 20.04。在发布Ubuntu 22.04之前，我们不会采用更新的Ubuntu版本（在容器中）。

Debian的靶心选择值得更多解释。它目前处于测试阶段，我们不知道何时发货。 Debian和.NET版本之间存在不协调的竞争，我们相信.NET 6将会失去竞争。一旦开始为新的.NET版本发布映像，我们就不会更改所使用的基本映像。我们现已将Debian 10（“破坏者”）用于多个版本。鉴于我们将支持.NET 6三年了，该该告别了。

从预览1开始，如果拉6.0标记，将使用靶心图像。 Bullseye尚未集成到我们的CI环境中，但是，手动测试表明它已经是可靠的发行版，并且与buster兼容。如果您有任何问题，请给我们反馈。

rich @ mazama：〜$ docker run --rm mcr.microsoft.com/dotnet/sdk:6.0 cat / etc / debian_versionbullseye / sidrich @ mazama：〜$ docker run --rm mcr.microsoft.com/dotnet/sdk:5.0 cat /etc/debian_version10.8rich@mazama:~$ docker run --rm mcr.microsoft.com/dotnet/sdk:3.1 cat /etc/debian_version10.8rich@mazama:~$ docker run --rm mcr.microsoft.com /dotnet/sdk:2.1 cat /etc/debian_version9.13

这一系列命令应该使我们的目标更加清晰，并且与我们为以前的.NET版本所做的选择形成对比。释放靶心后，第一个命令的输出将为11.0。

让我们继续介绍Apple Silicon的示例。当您了解我们的.NET 5容器示例需要在Apple Silicon计算机上运行x64仿真时，提取现有的.NET 5容器示例会发生什么。让我们来看看。

那是Arm64图片。这可能会让您感到惊讶。 .NET 5已经在Linux上支持Arm64，这就是您在该图中看到的内容。因此，毫不奇怪。当您运行Linux容器时，您正在运行Linux，而不是macOS。我们曾尝试在Apple Silicon上运行amd64 .NET映像，但目前似乎无法正常运行。

作为附带说明，我们针对2021年的容器图像启动了一个新的博客文章系列，第一个是使用.NET容器保持安全。

在每个预览中，我将描述一个或两个.NET 6主题。我将从使用运行时执行信息（PGO）改善启动和吞吐量开始。

自.NET成立以来，我们一直在使用PGO。 PGO的目标是优化二进制代码中的本机代码，以使其更有效地由CPU和计算机的其他方面执行。优化的代码使应用程序启动和运行更快，可以减少内存使用量甚至磁盘空间。为此，您可以采用许多技术。我们利用PGO（本机运行时）的优势，该PGO由我们在Windows，macOS和Linux上使用的C ++编译器提供。这是非常相关且重要的，但与该主题无关。

该主题与RyuJIT编译器在运行时或通过crossgen工具生成的本机代码有关（转换为现成的本机代码格式）。 Crossgen和RyuJIT已经支持PGO，但无论是从可用性还是在性能方面，我们都希望大幅改进此功能。我们不能将C ++编译器的PGO功能用于RyuJIT或通过crossgen进行扩展，因为RyuJIT并不是基于C ++编译器构建的（从代码生成的意义上来说）。

配置文件引导的优化（PGO）有很多。我从一个类比开始。您正沿着一条大高速公路缓慢行驶，希望您已经回家。您自己想：“造成这种交通拥堵的主要原因不是数量过多，而是一群不协调的驾驶员在本地进行优化的结果，这些驾驶员仅根据前方一辆汽车的刹车灯进行优化。这一切的悲剧！”在流量受到概要文件引导和优化的世界中，计算机将记录每日的流量模式，然后根据先前观察到的流量模式，为每辆汽车计算最佳的米距路径，并以恒定的指令流发送给每个汽车自动驾驶汽车计算机。流量将在全球范围内针对效率和安全性进行优化。因此，您每天至少要提前半小时回家。政府将能够推迟高速公路扩建项目，而将这笔钱用于资助学校和公园。

一种PGO技术是热冷拆分：将在二进制文件中最常调用的代码放在一起，将不常用的代码放到单独的组中。理想情况下，由于处于磁盘中已加载页面的相同物理顺序中，因此一系列方法调用（或基本块访问）中接下来需要的代码已被加载到CPU缓存中。在那种情况下，方法或基本块调用快如闪电（在CPU允许的范围内）。我们还进行了第三次拆分-“非常冷”分组-根本没有预编译本机代码，例如，对于引发异常的else子句。如果需要，可以将非常冷的代码进行JIT处理，这可能与性能无关。如果我们可以为非常寒冷的状态找到很多候选者，那么我们可以生成明显更小的二进制文件。

PGO（通常不只是.NET）并不普遍，因为PGO至少在传统模型上很难做到很好。这些工具通常很笨重，并且在处理过程中需要非常注意细节。您必须定期进行“培训”练习，在此过程中，您会在各种情况下运行应用程序，同时工具会收集有关应用程序的数据。然后，您将该数据提供给编译器（在本例中为crossgen）。然后，您必须验证您对结果满意。然后，您必须进行冲洗和重复操作，既可以改善您训练所用的场景，又要考虑开发过程中应用程序的变化。如果要获得最佳结果，必须对PGO有条不紊地遵循所有规定的步骤。这是一个非常累人和令人沮丧的过程。

到目前为止，这是对.NET的PGO的描述。在.NET 6中，我们计划执行以下操作：

创建一组针对易用性的PGO培训和数据处理新工具。 发布.NET库的培训数据，以便其他人（如Red Hat）可以使用，扩充它并共享培训数据。 我们希望PGO可以为启动和吞吐量带来10％左右的胜利。 对于计算密集型工作负载，好处可能更大。 我们期望需要两个版本才能实现我们的愿景。 我们仍在定义exa ......