.NET 生态系统的蜕变之 .NET 6

.NET 6 是自.NET 4 框架以来生态系统看到的最大版本更新，虽然.NET Core 是2014年开始非常大的一项重大战略举措，但是.NET 6是真正的具有强大动力的非常重要的版本。

2021年11月9日即将正式发布的.NET 6, 也许你认为.NET 5才刚刚发布，我才刚开始使用.NET Core 3.1, .NET6 就又要发布了 ，没错的，.NET 5是2020年11月10日发布，.NET Core 3.1早在2019年12月就发布了，微软已经承诺了每年都会发布一个版本的.NET , .NET 6正是按照时间表发布的版本。和这个版本发布节奏对应有一个支持政策：https://dotnet.microsoft.com/platform/support/policy/dotnet-core#cadence

从.NET 5开始，奇数版本版本18个月修补丁周期，而偶数版本有 三年 的修补丁周期。如果您已经将应用迁移到.NET Core 3.1，请注意，它有一个为期三年的修补丁周期，将于 2022 年 12 月结束;如果您仍在任何之前版本的 .NET Core上，则您目前已不在支持周期内。虽然尚未宣布对.NET框架 4.6.2 及以后的支持正式结束，但微软表示，.NET 框架 4.8 是.NET 框架的最后一个主要版本，将会随Windows 的支持计划更新：新的功能开发应针对以前称为 .NET Core（例如.NET 6）的平台。

.NET 6 带来了许多性能改进和生产力提升，而且还是一个长期支持版本 。在.NET 的每个连续版本中，.NET 在执行速度和内存使用方面都取得了一些令人印象深刻的进步。如果你一直没有跟踪， 你很可能会被. NET 框架的累积收益吹走。这一点你可以看看Techempower的测试的报告，具体参见 https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite

变化很大

我们从 .NET 5开始向前看，作为长期支持 （LTS） 版本，.NET 6 代表着进一步的改进，并具有大量的设计和性能改进。我们将主要看看ASP.NET 6 运行时间的性能改进列表和.NET 6 中的中断更改，可以看到变化非常大。

C# 语言更新

C#语言的最新版本是10.0，有几个有趣的变化，对于爱整洁的csharper 来说，全局引用（Global using）和 文件范围的命名空间 是很好的互补。现在，您可以声明适用于整个编译单元（很可能是项目）的全局使用，并避免到每个文件顶部的去添加相同指令集。文件范围的命名空间还允许您声明适用于给定文件中所有代码的命名空间，无需单行无需更多匹配卷曲大括号，源文件中的凹痕级别也较少。

以前

CSharp9_Widget.cs

using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class Widget
	{
		private List<WidgetPart> _widgetParts;
		public IEnumerable<WidgetPart> RequiredParts => 
			_widgetParts;

		public bool RequiresPart(int partId) => 
			_widgetParts.Any(x => x.Id == partId);
	}
}

CSharp9_WidgetPartsInventory.cs

using System;
using System.Collections.Generic;
using System.Linq;

namespace MyNamespace.Data
{
	class WidgetPartsInventory
	{
		private Dictionary<int, WidgetPart> _widgetPartsById;

		public bool HavePartsToBuildWidget(Widget widget) => 
			widget.RequiredParts.All(p => 
				_widgetPartsById.ContainsKey(p.Id));
	}
}

现在：

CSharp10_GlobalUsing.cs

global using System;
global using System.Collections.Generic;
global using System.Linq;

CSharp10_Widget.cs

namespace MyNamespace.Data;

class Widget
{
	private List<WidgetPart> _widgetParts;
	public IEnumerable<WidgetPart> RequiredParts => _widgetParts;

	public bool RequiresPart(int partId) => 
		_widgetParts.Any(x => x.Id == partId);
}

CSharp10_WidgetPartsInventory.cs

namespace MyNamespace.Data;

class WidgetPartsInventory
{
	private Dictionary<int, WidgetPart> _widgetPartsById;

	public bool HavePartsToBuildWidget(Widget widget) => 
		widget.RequiredParts.All(p => 
			_widgetPartsById.ContainsKey(p.Id));
}

还有其他一些与Record、模式和插值字符串相关的更新，但这些更新大多是语法糖。

ASP.NET Core 更新

如果你阅读每个版本的说明，很容易看到 ASP.NET Core 是一个核心，从网络主机和最小 API，热重载 到blazor都有很多感兴趣特性。

网络主机和最小 API

从 ASP.NET Core开始，每个应用程序都将应用初始化代码拆分为Program.cs（用于创建 Web 主机）和"Startup.cs（用于配置路由和 IoC 容器配置等应用程序问题）中，通常包含的两个单独的Class。特别是Startup类有一种神奇的感觉，它的方法从来没有被开发人员直接调用。而是WebHost在幕后自动调用配置方法。

ASP.NET团队分析了这个设计，并与其他 Web 框架相比，认为设置涉及的东西太多。因此，最小的API概念诞生了。 现在，应用程序初始化可以全部包含在一个文件中。而且你可能感到奇怪，Main方法都不需要了。可以在应用设置中定义路由，从而大大减少代码数量以启动和运行一个应用程序。

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

当然如果你仍然喜欢将服务设置与应用配置分离的组织样式，你仍然可以为 IServiceCollection 和 IApplicationBuilder 创建扩展方法，并从构建器和应用程序对象调用它们。

Hot Reload

几年来，许多 Javascript 框架都支持热重载，现在它也成为 C#中 ASP.NET Core应用的标配：通过热重加载，您可以在应用运行期间（在调试器下）编辑您的 C#代码，并且您的代码更改将自动反映在您的应用中，而不会丢失应用状态。换句话说，应用程序不需要重新启动。对于调试和交互式开发工作流程来说，这应该是一个很好的改进。 这个功能对于开发来说非常重要，就是这个小功能微软近日激怒了开源.NET社区，好消息是微软听取了社区的声音，恢复了通过CLI支持HotReload功能。具体参见 https://www.cnblogs.com/shanyou/p/15450214.html

Blazor

在 ASP.NET Core 6 里面有大量的更新是关于Blazor。例如，Blazor 应用程序现在可以直接编译到 WebAssembly，以便在 IL 解释（即.NET 本地编译）版本的相同代码上来提高应用程序速度。本地编译/调试体验仍然很快，因为漫长的编译时间仅适用于包装/发布。说到性能，Blazor WebAssembly可实现客户端代码的多线程。Javascript 受制于浏览器中的单线程。真正的多线程为可以从并行处理中受益的应用程序开辟了一些新的可能性（当然，这取决于浏览器的支持）。

还有一个非常有趣的功能，使 Blazor 可用于通过 MAUI 编写桌面应用程序。 Blazor 的最大好处就是开发人员可以完全用 C# 编写 Web 应用程序，而不需要为了写前端必须切换到 Javascript。 如果没有 C# 和 Javascript 之间的额外接缝，前端和后端代码之间就不需要映射层。 可以在两侧使用相同的 C# 模型，这意味着需要的代码更少，因此开发应用程序所需的时间也更少。 Blazor 桌面进一步扩展了这一概念，以允许此共享代码现在也可以与桌面应用程序无缝集成。

MAUI

MAUI 是 Multi-platform App UI 的缩写，是微软对跨平台 UI 框架的下一个尝试。 MAUI 是 Xamarin 的演进，还包括桌面平台。 它允许从单个代码库针对 iOS、Android、macOS 和 Windows。 MAUI 处理对本机平台 API 的抽象，因此您可以以与平台无关的方式访问设备传感器等内容。 对 Xamarin 的一种印象是，它们最终得到的界面很少，而且在任何平台上都不太好看。 MAUI 将如何解决这一问题还有待观察。 如果你关心的是跨多个平台的开发速度和维护成本，那么 MAUI 值得仔细研究。 MAUI 要在2022年的第二个季度正式发布，建议当前采取观望的方法，进行小的尝试以了解平台在全面采用之前的长期发展方向。