点击上方蓝字
关注我们
(本文阅读时间:15分钟)
欢迎使用 .NET 6。今天的版本是.NET 团队和社区一年多努力的结果。C# 10 和 F# 6 提供了语言改进,使您的代码更简单、更好、性能大幅提升,我们已经看到微软降低了托管云服务的成本。.NET 6 是第一个原生支持 Apple Silicon (Arm64) 的版本,并且还针对 Windows Arm64 进行了改进。我们构建了一个新的动态配置文件引导优化 (PGO) 系统,该系统可提供仅在运行时才可能进行的深度优化。使用dotnet monitor 和 OpenTelemetry 改进了云诊断。WebAssembly 支持更有能力和性能。为HTTP/3添加了新的 API ,处理 JSON、数学和直接操作内存。.NET 6 将支持三年。开发人员已经开始将应用程序升级到 .NET 6,我们在生产中听到了很好的早期成果。.NET 6 已为您的应用程序做好准备。
您可以下载适用于 Linux、macOS 和 Windows 的.NET 6 。
安装程序和二进制文件
容器图像
Linux 软件包
发行说明
API 差异
已知的问题
GitHub 问题跟踪器
请参阅 ASP.NET Core、Entity Framework、Windows Forms、.NET MAUI、YARP 和 dotnet 监视器帖子,了解各种场景中的新增功能。
.NET 6 下载
https://dotnet.microsoft.com/zh-cn/download/dotnet/6.0
.NET 6 亮点
.NET 6 是
使用 Microsoft 服务、其他公司运行的云应用程序和开源项目进行生产压力测试。
作为最新的长期支持 (LTS) 版本支持三年。
跨浏览器、云、桌面、物联网和移动应用程序的统一平台,所有这些都使用相同的 .NET 库并能够轻松共享代码。
性能得到了极大的提高,尤其是文件 I/O,这共同导致了执行时间、延迟和内存使用的减少。
C# 10 提供了语言改进,例如记录结构、隐式使用和新的 lambda 功能,而编译器添加了增量源生成器。F# 6添加了新功能,包括基于任务的异步、管道调试和众多性能改进。
Visual Basic 在 Visual Studio 体验和 Windows 窗体项目打开体验方面有所改进。
Hot Reload 使您能够跳过重新构建和重新启动您的应用程序以查看新更改(在您的应用程序运行时),Visual Studio 2022 和 .NET CLI 支持 C# 和 Visual Basic。
云诊断已通过 OpenTelemetry 和 dotnet monitor 得到改进,现在在生产中支持并在 Azure 应用服务中可用。
JSON API 的功能更强大,并且通过序列化程序的源生成器具有更高的性能。
ASP.NET Core 中引入的最小 API 可简化入门体验并提高 HTTP 服务的性能。
Blazor 组件现在可以从 JavaScript 呈现并与现有的基于 JavaScript 的应用程序集成。
Blazor WebAssembly (Wasm) 应用程序的 WebAssembly AOT编译,以及对运行时重新链接和本机依赖项的支持。
使用 ASP.NET Core 构建的单页应用程序现在使用更灵活的模式,可与 Angular、React 和其他流行的前端 JavaScript 框架一起使用。
添加了 HTTP/3,以便 ASP.NET Core、HttpClient 和 gRPC 都可以与 HTTP/3 客户端和服务器交互。
File IO 现在支持符号链接,并且通过 re-written-from-scratch 大大提高了性能FileStream。
通过支持 OpenSSL 3、ChaCha20Poly1305 加密方案和运行时深度防御缓解,特别是 W^X和CET,安全性得到了改进。
可以为 Linux、macOS 和 Windows(以前只有 Linux)发布单文件应用程序(免提取)。
IL 修整现在更加强大和有效,新的警告和分析器可确保正确的最终结果。
添加了源生成器和分析器,可帮助您生成更好、更安全和更高性能的代码。
源代码构建使 Red Hat 等组织能够从源代码构建 .NET 并向其用户提供自己的构建。
该版本包括大约一万次 git 提交。即使这篇文章很长,它也跳过了许多改进。您必须下载并试用.NET 6 才能看到所有新功能。
支持
.NET 6 是一个长期支持 (LTS) 版本,将支持三年。它支持多种操作系统,包括 macOS Apple Silicon 和 Windows Arm64。
Red Hat 与 .NET 团队合作,在 Red Hat Enterprise Linux 上支持 .NET。在 RHEL 8 及更高版本上,.NET 6 将可用于 AMD 和 Intel (x64_64)、ARM (aarch64) 以及 IBM Z 和 LinuxONE (s390x) 架构。
请开始将您的应用程序迁移到 .NET 6,尤其是 .NET 5 应用程序。我们从早期采用者那里听说,从 .NET Core 3.1 和 .NET 5 升级到 .NET 6 很简单。
Visual Studio 2022 和 Visual Studio 2022 for Mac 支持 .NET 6 。Visual Studio 2019、Visual Studio for Mac 8 或 MSBuild 16 不支持它。如果要使用 .NET 6,则需要升级到Visual Studio 2022(现在也是 64 位)。Visual Studio Code C# 扩展支持 .NET 6 。
Azure App 服务:
Azure Functions 现在支持在 .NET 6 中运行无服务器函数。
App Service .NET 6 GA Announcement 为 ASP.NET Core 开发人员提供了信息和详细信息,他们很高兴今天开始使用 .NET 6。
Azure 静态 Web 应用现在支持带有 Blazor WebAssembly 前端和 Azure Function API 的全栈 .NET 6 应用程序。
注意:如果您的应用已经在应用服务上运行 .NET 6 预览版或 RC 版本,则在将 .NET 6 运行时和 SDK 部署到您所在区域后,它将在第一次重新启动时自动更新。如果您部署了一个独立的应用程序,您将需要重新构建和重新部署。
统一扩展平台
.NET 6 为浏览器、云、桌面、物联网和移动应用程序提供了一个统一的平台。底层平台已更新,可满足所有应用类型的需求,并便于在所有应用中重用代码。新功能和改进同时适用于所有应用程序,因此您在云或移动设备上运行的代码的行为方式相同并具有相同的优势。
.NET 开发人员的范围随着每个版本的发布而不断扩大。机器学习和 WebAssembly 是最近添加的两个。例如,通过机器学习,您可以编写在流数据中查找异常的应用程序。使用 WebAssembly,您可以在浏览器中托管 .NET 应用程序,就像 HTML 和 JavaScript 一样,或者将它们与 HTML 和 JavaScript 混合使用。
最令人兴奋的新增功能之一是.NET Multi-platform App UI (.NET MAUI)。您现在可以在单个项目中编写代码,从而跨桌面和移动操作系统提供现代客户端应用程序体验。.NET MAUI 将比 .NET 6 稍晚发布。我们在 .NET MAUI 上投入了大量时间和精力,很高兴能够发布它并看到 .NET MAUI 应用程序投入生产。
当然,.NET 应用程序也可以在家中使用 Windows 桌面(使用 Windows Forms 和WPF)以及使用 ASP.NET Core 在云中。它们是我们提供时间最长的应用程序类型,并且仍然非常受欢迎,我们在 .NET 6 中对其进行了改进。
面向.NET 6
继续以广泛平台为主题,在所有这些操作系统上编写 .NET 代码很容易。
要以 .NET 6 为目标,您需要使用 .NET 6 目标框架,如下所示:
<TargetFramework>net6.0</TargetFramework>
net6.0 Target Framework Moniker (TFM) 使您可以访问 .NET 提供的所有跨平台 API。如果您正在编写控制台应用程序、ASP.NET Core 应用程序或可重用的跨平台库,这是最佳选择。
如果您针对特定操作系统(例如编写Windows 窗体或 iOS 应用程序),那么还有另一组 TFM(每个都针对不言而喻的操作系统)供您使用。它们使您可以访问所有 net6.0的API以及一堆特定于操作系统的 API。
• net6.0-android
• net6.0-ios
• net6.0-maccatalyst
• net6.0-tvos
• net6.0-windows
每个无版本 TFM 都相当于针对 .NET 6 支持的最低操作系统版本。如果您想要具体或访问更新的 API,可以指定操作系统版本。
net6.0 和 net6.0-windows TFMs 都支持(与 .NET 5 相同)。Android 和 Apple TFM 是 .NET 6 的新功能,目前处于预览阶段。稍后的 .NET 6 更新将支持它们。
操作系统特定的 TFM 之间没有兼容性关系。例如,net6.0-ios 与 net6.0-tvos 不兼容。如果您想共享代码,您需要使用带有 #if 语句的源代码或带有 net6.0 目标代码的二进制文件来实现。
性能
自从我们启动 .NET Core 项目以来,该团队一直在不断地关注性能。Stephen Toub 在记录每个版本的 .NET 性能进展方面做得非常出色。欢迎查看在 .NET 6 中的性能改进的帖子。在这篇文章中,里面包括您想了解的重大性能改进,包括文件 IO、接口转换、PGO 和 System.Text.Json。
▌动态 PGO
动态轮廓引导优化 (PGO)可以显着提高稳态性能。例如,PGO 为 TechEmpower JSON“MVC”套件的每秒请求数提高了 26%(510K -> 640K)。
动态 PGO 建立在分层编译的基础上,它使方法能够首先非常快速地编译(称为“第 0 层”)以提高启动性能,然后在启用大量优化的情况下随后重新编译(称为“第 1 层”)一旦该方法被证明是有影响的。该模型使方法能够在第 0 层中进行检测,以允许对代码的执行进行各种观察。在第 1 层重新调整这些方法时,从第 0 层执行收集的信息用于更好地优化第 1 层代码。这就是机制的本质。
动态 PGO 的启动时间将比默认运行时稍慢,因为在第 0 层方法中运行了额外的代码来观察方法行为。
要启用动态 PGO,请在应用程序将运行的环境中设置 DOTNET_TieredPGO=1。您还必须确保启用分层编译(默认情况下)。动态 PGO 是可选的,因为它是一种新的且有影响力的技术。我们希望发布选择加入使用和相关反馈,以确保它经过全面压力测试。我们对分层编译做了同样的事情。至少一个非常大的 Microsoft 服务支持并已在生产中使用动态 PGO。我们鼓励您尝试一下。
您可以在.NET 6中的性能帖子中看到更多关于动态 PGO 优势的信息,包括以下微基准,它测量特定 LINQ 枚举器的成本。
private IEnumerator<long> _source = Enumerable.Range(0, long.MaxValue).GetEnumerator();[Benchmark]
public void MoveNext() => _source.MoveNext();
这是有和没有动态 PGO 的结果。
方法 | 意思是 | 代码大小 |
PGO 已禁用 | 1.905 纳秒 | 30乙 |
启用 PGO | 0.7071 纳秒 | 105乙 |
这是一个相当大的差异,但代码大小也有所增加,这可能会让一些读者感到惊讶。这是由 JIT 生成的汇编代码的大小,而不是内存分配(这是一个更常见的焦点)。.NET 6 性能帖子对此有很好的解释。
PGO 实现中常见的一种优化是“热/冷分离”,其中经常执行的方法部分(“热”)在方法开始时靠近在一起,而不经常执行的方法部分(“冷”)是移到方法的末尾。这样可以更好地使用指令缓存,并最大限度地减少可能未使用的代码负载。
作为上下文,接口调度是 .NET 中最昂贵的调用类型。非虚拟方法调用是最快的,甚至更快的是可以通过内联消除的调用。在这种情况下,动态 PGO 为 MoveNext 提供了两个(替代)调用站点。第一个 - 热的 - 是对 Enumerable+RangeIterator.MoveNext 的直接调用,另一个 - 冷的 - 是通过 IEnumerator<int> 的虚拟接口调用。如果大多数时候最热门的人都被叫到,那将是一个巨大的胜利。
这就是魔法。当 JIT 检测此方法的第 0 层代码时,包括检测此接口调度以跟踪每次调用时 _source 的具体类型。JIT 发现每次调用都在一个名为 Enumerable+RangeIterator 的类型上,这是一个私有类,用于在 Enumerable 实现内部实现 Enumerable.Range。因此,对于第 1 层,JIT 已发出检查以查看 _source 的类型是否为 Enumerable+RangeIterator:如果不是,则跳转到我们之前强调的执行正常接口调度的冷部分。但如果是 - 基于分析数据,预计绝大多数时间都是这种情况 - 然后它可以继续直接调用非虚拟化的 Enumerable+RangeIterator.MoveNext 方法。不仅如此,它还认为内联 MoveNext 方法是有利可图的。最终效果是生成的汇编代码有点大,但针对预期最常见的确切场景进行了优化。当我们开始构建动态 PGO 时,这些就是我们想要的那种胜利。
动态 PGO 将在 RyuJIT 部分再次讨论。
▌文件 IO 改进
FileStream 几乎完全用 .NET 6 重写,重点是提高异步文件 IO 性能。在 Windows 上,实现不再使用阻塞 API,并且可以快几倍!我们还改进了所有平台上的内存使用。在第一次异步操作(通常分配)之后,我们已经使异步操作免分配!此外,我们已经使 Windows 和 Unix 实现不同的边缘情况的行为统一(这是可能的)。
这种重写的性能改进使所有操作系统受益。对 Windows 的好处是最大的,因为它远远落后。macOS 和 Linux 用户也应该会看到显着 FileStream 的性能改进。
以下基准将 100 MB 写入新文件。
private byte[] _bytes = new byte[8_000];[Benchmark]
public async Task Write100MBAsync()
{using FileStream fs = new("file.txt", FileMode.Create, FileAccess.Write, FileShare.None, 1, FileOptions.Asynchronous);for (int i = 0; i < 100_000_000 / 8_000; i++)await fs.WriteAsync(_bytes);
}
在带有 SSD 驱动器的 Windows 上,我们观察到4倍的加速和超过1200倍的分配下降:
方法 | 运行 | 意思是 | 比率 | 已分配 |
写100MBAsync | .NET 5.0 | 1,308.2 毫秒 | 1.00 | 3,809 KB |
写100MBAsync | .NET 6.0 | 306.8 毫秒 | 0.24 | 3 KB |
我们还认识到需要更高性能的文件 IO 功能:并发读取和写入,以及分散/收集 IO。针对这些情况,我们为 System.IO.File 和 System.IO.RandomAccess 类引入了新的 API。
async Task AllOrNothingAsync(string path, IReadOnlyList<ReadOnlyMemory<byte>> buffers)
{using SafeFileHandle handle = File.OpenHandle(path, FileMode.Create, FileAccess.Write, FileShare.None, FileOptions.Asynchronous,preallocationSize: buffers.Sum(buffer => buffer.Length)); // hint for the OS to pre-allocate disk spaceawait RandomAccess.WriteAsync(handle, buffers, fileOffset: 0); // on Linux it's translated to a single sys-call!
}
该示例演示:
使用新 File.OpenHandle API 打开文件句柄。
使用新的预分配大小功能预分配磁盘空间。
使用新的 Scatter/Gather IO API写入文件。
预分配大小功能提高了性能,因为写入操作不需要扩展文件,并且文件不太可能被碎片化。这种方法提高了可靠性,因为写入操作将不再因空间不足而失败,因为空间已被保留。Scatter/Gather IO API 减少了写入数据所需的系统调用次数。
▌更快的接口检查和转换
界面铸造性能提高了 16% - 38%。这种改进对于 C# 与接口之间的模式匹配特别有用。
这张图表展示了一个有代表性的基准测试的改进规模。
将 .NET 运行时的一部分从 C++ 迁移到托管 C# 的最大优势之一是它降低了贡献的障碍。这包括接口转换,它作为早期的 .NET 6 更改移至 C#。.NET 生态系统中懂 C# 的人比懂 C++ 的人多(而且运行时使用具有挑战性的 C++ 模式)。仅仅能够阅读构成运行时的一些代码是培养以各种形式做出贡献的信心的重要一步。
归功于 Ben Adams。
▌System.Text.Json 源生成器
我们为 System.Text.Json 添加了一个源代码生成器,它避免了在运行时进行反射和代码生成的需要,并且可以在构建时生成最佳序列化代码。序列化程序通常使用非常保守的技术编写,因为它们必须如此。但是,如果您阅读自己的序列化源代码(使用序列化程序),您可以看到明显的选择应该是什么,可以使序列化程序在您的特定情况下更加优化。这正是这个新的源生成器所做的。
除了提高性能和减少内存之外,源代码生成器还生成最适合装配修整的代码。这有助于制作更小的应用程序。
序列化POCO是一种非常常见的场景。使用新的源代码生成器,我们观察到序列化速度比我们的基准快 1.6 倍。
方法 | 意思是 | 标准差 | 比率 |
串行器 | 243.1 纳秒 | 9.54 纳秒 | 1.00 |
SrcGenSerializer | 149.3 纳秒 | 1.91 纳秒 | 0.62 |
TechEmpower 缓存基准测试平台或框架对来自数据库的信息进行内存缓存。基准测试的 .NET 实现执行缓存数据的 JSON 序列化,以便将其作为响应发送到测试工具。
请求/秒 | 要求 | |
net5.0 | 243,000 | 3,669,151 |
网6.0 | 260,928 | 3,939,804 |
net6.0 + JSON 源码生成 | 364,224 | 5,499,468 |
我们观察到约 100K RPS 增益(增加约 40%)。与MemoryCache 性能改进相结合时,.NET 6 的吞吐量比 .NET 5 高 50% !
C# 10
欢迎来到 C# 10。C# 10的一个主要主题是继续从C# 9中的顶级语句开始的简化之旅。新功能从 Program.cs 中删除了更多的仪式,导致程序只有一行。他们的灵感来自于与没有 C# 经验的人(学生、专业开发人员和其他人)交谈,并了解什么对他们来说最有效且最直观。
大多数.NET SDK 模板都已更新,以提供现在可以使用 C# 10 实现的更简单、更简洁的体验。我们收到反馈说,有些人不喜欢新模板,因为它们不适合专家,删除面向对象,删除在编写 C# 的第一天学习的重要概念,或鼓励在一个文件中编写整个程序。客观地说,这些观点都不正确。新模型同样适用于作为专业开发人员的学生。但是,它与 .NET 6 之前的 C 派生模型不同。
C# 10 中还有其他一些功能和改进,包括记录结构。
▌全局使用指令
全局 using 指令让您 using 只需指定一次指令并将其应用于您编译的每个文件。
以下示例显示了语法的广度:
• global using System;
• global using static System.Console;
• global using Env = System.Environment;
您可以将global using语句放在任何 .cs 文件中,包括在 Program.cs 中。
隐式 usings 是一个 MSBuild 概念,它会根据 SDK自动添加一组指令。例如,控制台应用程序隐式使用不同于 ASP.NET Core。
隐式使用是可选的,并在 a 中启用 PropertyGroup:
<ImplicitUsings>enable</ImplicitUsings>
隐式使用对于现有项目是可选的,但默认包含在新 C# 项目中。有关详细信息,请参阅隐式使用。
▌文件范围的命名空间
文件范围的命名空间使您能够声明整个文件的命名空间,而无需将剩余内容嵌套在{ ... }中. 只允许一个,并且必须在声明任何类型之前出现。
新语法是单个的一行:
namespace MyNamespace;class MyClass { ... } // Not indented
这种新语法是三行缩进样式的替代方案:
namespace MyNamespace
{class MyClass { ... } // Everything is indented
}
好处是在整个文件位于同一个命名空间中的极其常见的情况下减少缩进。
▌记录结构
C# 9 将记录作为一种特殊的面向值的类形式引入。在 C# 10 中,您还可以声明结构记录。C# 中的结构已经具有值相等,但记录结构添加了 == 运算符和 IEquatable<T> 的实现,以及基于值的 ToString 实现:
public record struct Person
{public string FirstName { get; init; }public string LastName { get; init; }
}
就像记录类一样,记录结构可以是“位置的”,这意味着它们有一个主构造函数,它隐式声明与参数对应的公共成员:
public record struct Person(string FirstName, string LastName);
但是,与记录类不同,隐式公共成员是可变的自动实现的属性。这样一来,记录结构就成为了元组的自然成长故事。例如,如果您有一个返回类型(string FirstName, string LastName),并且您希望将其扩展为命名类型,您可以轻松地声明相应的位置结构记录并维护可变语义。
如果你想要一个具有只读属性的不可变记录,你可以声明整个记录结构 readonly(就像你可以其他结构一样):
public readonly record struct Person(string FirstName, string LastName);
C# 10 不仅支持记录结构,还支持所有结构以及匿名类型的 with 表达式:
var updatedPerson = person with { FirstName = "Mary" }
F# 6
F# 6旨在让 F# 更简单、更高效。这适用于语言设计、库和工具。我们对 F# 6(及更高版本)的目标是消除语言中让用户感到惊讶或阻碍学习 F# 的极端情况。我们很高兴能与 F# 社区合作进行这项持续的努力。
▌让 F# 更快、更互操作
新语法task {…}直接创建一个任务并启动它。这是 F# 6 中最重要的功能之一,它使异步任务更简单、性能更高,并且与 C# 和其他 .NET 语言的互操作性更强。以前,创建 .NET 任务需要使用async {…}来创建任务并调用 Async.StartImmediateAsTask。
该功能 task {…}建立在称为“可恢复代码”RFC FS-1087的基础之上。可恢复代码是一个核心特性,我们希望在未来使用它来构建其他高性能异步和屈服状态机。
F# 6 还为库作者添加了其他性能特性,包括 InlineIfLambda 和F# 活动模式的未装箱表示。一个特别显着的性能改进在于列表和数组表达式的编译,现在它们的速度提高了4 倍,并且调试也更好、更简单。
▌让 F# 更易学、更统一
F# 6 启用expr[idx]索引语法。到目前为止,F# 一直使用 expr.[idx] 进行索引。删除点符号是基于第一次使用 F# 用户的反复反馈,点的使用与他们期望的标准实践有不必要的差异。在新代码中,我们建议系统地使用新的 expr[idx]索引语法。作为一个社区,我们都应该切换到这种语法。
F# 社区为使 F# 语言在 F# 6 中更加统一做出了重要改进。其中最重要的是消除了 F# 缩进规则中的一些不一致和限制。使 F# 更加统一的其他设计添加包括添加as图案;在计算表达式中允许“重载自定义操作”(对 DSL 有用);允许_丢弃use绑定并允许%B在输出中进行二进制格式化。F# 核心库添加了用于复制和更新列表、数组和序列的新函数,以及其他NativePtr内在函数。自 2.0 起弃用的 F# 的一些旧功能现在会导致错误。其中许多更改更好地使 F# 与您的期望保持一致,从而减少意外。
F# 6 还增加了对 F# 中其他“隐式”和“类型导向”转换的支持。这意味着更少的显式向上转换,并为 .NET 样式的隐式转换添加了一流的支持。F# 也进行了调整,以更好地适应使用 64 位整数的数字库时代,并隐式扩展了 32 位整数。
▌改进 F# 工具
F# 6 中的工具改进使日常编码更容易。新的“管道调试”允许您单步执行、设置断点并检查 F# 管道语法input |> f1 |> f2 的中间值。阴影值的调试显示已得到改进,消除了调试时常见的混淆源。F# 工具现在也更高效,F# 编译器并行执行解析阶段。F# IDE 工具也得到了改进。F# 脚本现在更加健壮,允许您通过global.json文件固定使用的 .NET SDK 版本。
热重载
Hot Reload 是另一个性能特性,专注于开发人员的生产力。它使您能够对正在运行的应用程序进行各种代码编辑,从而缩短您等待应用程序重新构建、重新启动或重新导航到您在进行代码更改后所在位置所需的时间。
Hot Reload 可通过dotnet watch CLI 工具和 Visual Studio 2022 使用。您可以将 Hot Reload 与多种应用类型一起使用,例如 ASP.NET Core、Blazor、.NET MAUI、控制台、Windows 窗体 (WinForms)、WPF、WinUI 3、Azure 函数等。
使用 CLI 时,只需使用 启动您的 .NET 6 应用程序dotnet watch,进行任何受支持的编辑,然后在保存文件时(如在 Visual Studio Code 中),这些更改将立即应用。如果不支持更改,详细信息将记录到命令窗口。
此图像显示了一个使用 dotnet watch. 我对.cs文件和.cshtml 文件进行了编辑(如日志中所述),两者都应用于代码并在不到半秒的时间内非常快速地反映在浏览器中。
使用 Visual Studio 2022 时,只需启动您的应用程序,进行支持的更改,然后使用新的“热重载”按钮(如下图所示)应用这些更改。您还可以通过同一按钮上的下拉菜单选择在保存时应用更改。使用 Visual Studio 2022 时,热重载可用于多个 .NET 版本,适用于 .NET 5+、.NET Core 和 .NET Framework。例如,您将能够对按钮的OnClickEvent 处理程序进行代码隐藏更改。应用程序的 Main 方法不支持它。
注意:RuntimeInformation.FrameworkDescription 中存在一个错误,该错误将在该图像中展示,很快就会修复。
Hot Reload 还与现有的 Edit and Continue 功能(在断点处停止时)以及用于实时编辑应用程序 UI 的 XAML Hot Reload 协同工作。目前支持 C# 和 Visual Basic 应用程序(不是 F#)。
安全
.NET 6 中的安全性得到了显着改进。它始终是团队关注的重点,包括威胁建模、加密和深度防御防御。
在 Linux 上,我们依赖 OpenSSL 进行所有加密操作,包括 TLS(HTTPS 必需)。在 macOS 和 Windows 上,我们依赖操作系统提供的功能来实现相同的目的。对于每个新版本的 .NET,我们经常需要添加对新版本 OpenSSL 的支持。.NET 6 增加了对OpenSSL 3的支持。
OpenSSL 3 的最大变化是改进的 FIPS 140-2模块和更简单的许可。
.NET 6 需要 OpenSSL 1.1 或更高版本,并且会更喜欢它可以找到的最高安装版本的 OpenSSL,直到并包括 v3。在一般情况下,当您使用的 Linux 发行版默认切换到 OpenSSL 3 时,您最有可能开始使用 OpenSSL 3。大多数发行版还没有这样做。例如,如果您在 Red Hat 8 或 Ubuntu 20.04 上安装 .NET 6,您将不会(在撰写本文时)开始使用 OpenSSL 3。
OpenSSL 3、Windows 10 21H1 和 Windows Server 2022 都支持ChaCha20Poly1305。您可以在 .NET 6 中使用这种新的经过身份验证的加密方案(假设您的环境支持它)。
感谢 Kevin Jones 对 ChaCha20Poly1305 的 Linux 支持。
我们还发布了新的运行时安全缓解路线图。重要的是,您使用的运行时不受教科书攻击类型的影响。我们正在满足这一需求。在 .NET 6 中,我们构建了W^X和英特尔控制流强制技术 (CET)的初始实现。W^X 完全受支持,默认为 macOS Arm64 启用,并且可以选择加入其他环境。CET 是所有环境的选择加入和预览。我们希望在 .NET 7 中的所有环境中默认启用这两种技术。
更多攻略欢迎转到下一篇文章,继续阅读哦!
了解更多.NET 6