政元软件做网站,长春站建筑风格,成都旅行社网站建设,网络策划人2020 中国.NET 开发者峰会正式启动 #xff0c;欢迎大家提交演讲主题或者购买超级早鸟票。今年11月10号 .NET 5.0 如约而至。这是.NET All in one后的第一个版本#xff0c;虽然不是LTS(Long term support)版本#xff0c;但是是生产环境可用的。微软从.NET 5 Preview 1就开… 2020 中国.NET 开发者峰会正式启动 欢迎大家提交演讲主题或者购买超级早鸟票。今年11月10号 .NET 5.0 如约而至。这是.NET All in one后的第一个版本虽然不是LTS(Long term support)版本但是是生产环境可用的。微软从.NET 5 Preview 1就开始在自己的网站上使用 .NET 5, (Bing.com、dot.net已升级并运行了数个月)同时早期的.NET Core版本可以直接升级到.NET 5. 有着微软得背书所以大家是可以放心使用的。接下来我们深入了解一下.NET 5.0这次带来了哪些新的特性。一.NET 5.0 的一些亮点(Highlights)1. 通过线上生产环境测试battle-tested) : .NET5.0 通过在Bing.com和dot.net 托管运行数个月全面通过了线上验证这证明这个版本是生产可用的2. 性能大幅提升GC、JIT、正则表达式、多线程和异步处理、集合、LINQ、网络访问、JSON序列化、gRPC等等了解详细可以访问Performance Improvements in .NET 5.0Arm64 Performance in .NET 5.0gRPC.3. C# 9和F# 9 的语言提升例如C9的顶级程序和记录recordF5提供了交互式编程并提高了.NET的性能。4. .NET库增强了Json序列化正则表达式和HTTPHTTP 1.1HTTP / 2的性能。这一点在第二条中已经有所涉及。5. P95 的延迟有所减少得益于GC、分层编译和其他组件的一些改进6.更好、更灵活的应用部署选项ClickOnce客户端应用程序发布单文件应用程序减小的容器映像大小以及添加的Server Core容器映像。7.平台支持的范围进一步扩展Windows Arm64和WebAssembly文中蓝色标注文档链接如下Performance Improvements in .NET 5.0https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/?https://devblogs.microsoft.com/dotnet/introducing-net-5?WT.mc_idDT-MVP-5003918Arm64 Performance in .NET 5.0https://devblogs.microsoft.com/dotnet/Arm64-performance-in-net-5/?https://devblogs.microsoft.com/dotnet/introducing-net-5?WT.mc_idDT-MVP-5003918gRPC.https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5?WT.mc_idDT-MVP-5003918Windows Arm64https://github.com/dotnet/runtime/issues/36699WebAssemblyhttps://github.com/dotnet/runtime/issues/38367二再看统一平台的愿景2019年5月6号微软发布了.NET 5.0 统一平台的愿景将来只会有一个.NET您将可以使用它来定位WindowsLinuxmacOSiOSAndroidtvOSwatchOS和WebAssembly等。实现这一愿景的第一步是整合.NET仓库即整合关键的.NET代码库 这是为.NET运行库和库提供一个存储库是在各处交付相同产品的前提。Blazor就是代码合并和.NET统一的最佳示例Blazor WebAssembly的运行时和库现在是从合并的dotnet /运行时仓库中构建的。这意味着服务器上的Blazor WebAssembly和Blazor使用与完全相同的代码ListT。代码整合后.NET Framework怎么办.NET Framework仍然是受支持的Microsoft产品并且每个新版本的Windows都将继续支持.NET Framework。去年微软宣布已停止向.NET Framework添加新功能逐步向.NET Core添加更多的.NET Framework API。这就意味着.NET Framework已经停更了版本目前停留在.NET Framework 4.8. 这也是没办法的事情统一后的.NET, 从.NET5.0开始迭代了。这次.NET 5.0的Release列表也能发现这个情况在上述情况下目前是将.NET Framework升级到.NET Core的最佳时机了。如果比较在意LTS版本也可以等到明年.NET 6统一升级。对于此微软的建议是对于.NET Framework客户端开发人员.NET 5.0支持Windows窗体和WPF。 对于.NET Framework服务器开发人员 如果采用ASP.NET Core才能使用.NET 5.0。对于Web Forms开发人员Blazor通过高效且更加现代的实现方式提供类似的开发人员体验。对于WCF服务器和Workflow用户可以查看支持这些框架的社区项目。以上对于统一后的.NET 5.0, 广大.NET Developers 可以放心、开心地去拥抱这次升级和统一这代表了.NET的未来。文中蓝色标注文档链接如下.NET 5.0 统一平台的愿景https://devblogs.microsoft.com/dotnet/introducing-net-5?WT.mc_idDT-MVP-5003918支持这些框架的社区项目https://devblogs.microsoft.com/dotnet/supporting-the-community-with-wf-and-wcf-oss-projects/三深入了解一下编程语言层面的提升C# 9 和 F# 5C#9和F#5是.NET 5.0版本的一部分被包含在.NET 5.0 SDK中。接下来详细看一下C# 9 的一些语言新特性F# 5用的比较少不再做详细介绍1. Top-level programs 顶级程序大家会问这是什么这是在顶级编写程序的一种更简单的方式一个更简单的 Program.cs 文件。我们知道原先在Program类中必须有Main函数这是程序的一个EntryPoint入口。using System;namespace NET5Demo
{class Program{static void Main(string[] args){Console.WriteLine(Hello World!);}}
} .NET 5引入Top-level programs 后我们不需要写Main函数了。可以直接这么写System.Console.WriteLine(Hello World!);
大家会有疑问真的没有Main函数了吗其实这是个语法糖我们通过IL Spy看一下反编译后的代码2. 逻辑模式和属性模式匹配(Logical and property patterns)我们可以使用not or and 实现更强的更灵活的逻辑模式匹配先看一个逻辑匹配的Demovar input Console.ReadKey();
if (input.KeyChar is Y or y)
{Console.WriteLine(You choosed yes!);
}
再看一个Switch的Demo int score 90;
switch (score)
{case 0:Console.WriteLine(0分.);break;case 0 and 60:Console.WriteLine(合格.);break;case 60 and 80:Console.WriteLine(优秀.);break;case 80 and 100:Console.WriteLine(卓越.);break;
}
属性模式匹配通过两个{}实现对对象属性的模式匹配。Type type Type.GetType(System.String);
if (type is not null and { FullName: System.String })
{Console.WriteLine(Its type is System.String.);
}
3. record类型record是一个新增的引用类型与class很像那么大家会问为什么增加一个record类型呢它的使用场景是什么呢答案为了方便比较数据是否一致。我们写个代码示意一下假设我们有个User类包含ID、Name、Gender、Tel几个属性如果我们要对比2个User对象是否相等我们可能需要逐个属性对比或重写Equals、GetHashCode方法。那么如果我们用record类型呢record User(int Id, string Name, int Gender, string Tel);
做个对象对比的Demovar userA new User(1, 小米, 1, 123456789);
var userB new User(1, 小米, 1, 123456789);
if (userA userB)
{Console.WriteLine(这是一个用户.);
}
总结一下record类型让开发省去了重写相等比较的业务逻辑同时简化了类型定义和初始化。4. 可空注解的增加和改进目前.NET library 类库已经全面设置了是否可空注解。其实这个特性其实在C# 8.0已经引入C#8.0 引入了“可为空引用类型”和“不可为空引用类型”使你能够对引用类型变量的属性作出重要声明 #nullable enable class A{ }即.NET 5.0的类库中已经全面更新了这个注解方便开发时进行查看。同时这次引入新的成员是否为空的注解MemberNotNull 和 MemberNotNullWhen例如以下的代码class UserManager
{User user new User(1, 小米, 1, 123456789);[MemberNotNull(nameof(user))]public string GetUserName(string id){return user.Name;}
}
编译器会智能提示CS8602警告文中蓝色标注文档链接如下C#8.0 引入了“可为空引用类型”和“不可为空引用类型”使你能够对引用类型变量的属性作出重要声明https://docs.microsoft.com/zh-cn/dotnet/csharp/nullable-references四工具类的新变化.NET 5.0 改进了Windows窗体设计器更改了目标框架适用于.NET 5.0及更高版本的方式更改了WinRT的支持方式以及其他的一些改进。1. Windows窗体设计器winform设计器Windows Forms设计器用于.NET Core 3.1和.NET 5.0已经在Visual Studio 16.8中进行了更新现在支持所有Windows Forms控件。它还支持WinForms控件的Telerik UI。设计器包括您期望的所有设计器功能包括拖放选择移动和调整大小剪切/复制/粘贴/删除控件与属性窗口集成事件生成等。数据绑定和对更广泛的第三方控件的支持即将推出。2. .NET 5.0目标框架新增一个Console类型工程后选择目标框架是.NET 5.0, 其Project文件内容是这样的Project SdkMicrosoft.NET.SdkPropertyGroupOutputTypeExe/OutputTypeTargetFrameworknet5.0/TargetFramework/PropertyGroup
/Project
新增一个Windows窗体应用工程后选择目标框架是.NET 5.0, 其Project文件内容是这样的Project SdkMicrosoft.NET.Sdk.WindowsDesktopPropertyGroupOutputTypeWinExe/OutputTypeTargetFrameworknet5.0-windows/TargetFrameworkUseWindowsFormstrue/UseWindowsForms/PropertyGroup
/Project
Windows桌面API包括Windows窗体WPF和WinRT仅在定位时可用net5.0-windows。同时也可以指定操作系统版本例如net5.0-windows7或net5.0-windows10.0.17763.0对于Windows October 2018 Update。如果要使用WinRT API则需要定位Windows 10版本。总结一下net5.0 是.NET 5.0的新目标框架绰号Target Framework MonikerTFM。net5.0结合并替换netcoreapp和netstandard TFM。net5.0支持.NET Framework兼容模式net5.0-windows 将用于公开Windows特定功能包括Windows窗体WPF和WinRT API。.NET 6.0将使用相同的方法并带有net6.0和将添加net6.0-ios和net6.0-android。特定于操作系统的TFM可以包含操作系统版本号例如net6.0-ios14。可移植的API如ASP.NET Core可与一起使用net5.0。带有的Xamarin形式也是如此net6.0。3. WinRT Interop的重大改进在以Windows API为目标这一主题上微软已经移至一个新模型以作为.NET 5.0的一部分来支持WinRT API。这包括调用API在任一方向上CLR WinRT两个类型系统之间的数据封送处理以及打算在类型系统或ABI边界上统一对待的类型的统一即“投影类型” ”IEnumerableT并且IIterableT是示例。从.NET 5.0开始原有的WinRT互操作体系已被移除。这是一个巨大的变化。这意味着使用WinRT和.NET Core 3.x的应用程序和库需要重新开发对接并且不能按原样在.NET 5.0上运行。使用WinRT API的库将需要多目标来管理.NET Core 3.1和.NET 5.0之间的这种差异。未来.NET 将依靠Windows中的WinRT团队提供的新CsWinRT工具。它生成基于C的WinRT互操作程序集可以通过NuGet交付该程序集。Windows团队正是针对Windows中的WinRT API所做的。希望将WinRT在Windows上用作互操作系统的任何人都可以使用该工具以将本机API公开给.NET或将.NET API公开给本机代码。关于CsWinRT工具已经发布了1.0版本具体可以参考链接https://blogs.windows.com/windowsdeveloper/2020/11/10/announcing-c-winrt-version-1-0-with-the-net-5-ga-release/4. .NET Native Export/ .NET 本地导出即本机二进制文件启用导出功能。.NET 开发团队的Aaron Robinson一直在从事.NET Native Exports项目该项目为将.NET组件作为本机库发布提供了更完整的体验。.NET Native导出项目能够实现公开自定义的本地出口。不需要像COM这样的高级互操作技术。跨平台工作类似的实现技术还有Unmanaged ExportsDllExport5. 事件管道事件管道是在.NET Core 2.2中添加的新子系统和API可以在任何操作系统上执行性能和其他诊断调查。在.NET 5.0中事件管道已得到扩展以使事件探查器能够写入事件管道事件。对于以前依靠ETW在Windows上监视应用程序行为和性能的分析探查器来说是一个很好的方案和选择。这里不做详细展开了。6. 转储调试Dump分析调试调试托管代码需要了解托管对象和构造。数据访问组件DAC是运行时执行引擎的子集该引擎具有这些构造的知识并且可以在没有运行时的情况下访问这些托管对象。现在可以使用WinDBG或Windows在Windows上分析在Linux上收集的.NET Core进程转储dotnet dump analyze。本次发布还增加了对从macOS上运行的.NET进程捕获ELF转储的支持。由于ELF不是lldbmacOS上的本机可执行文件像这样的本地调试器将无法与这些转储一起使用文件格式因此我们将其设为启用功能。要在macOS上支持转储收集请设置环境变量COMPlus_DbgEnableElfDumpOnMacOS1。可以使用来分析产生的转储dotnet dump analyze。7. 打印环境信息随着.NET扩展了对新操作系统和芯片体系结构的支持有时需要一种打印环境信息的方法。.NET 5.0 创建了一个简单的.NET工具来执行此操作称为dotnet-runtimeinfo。可以使用以下命令安装和运行该工具:dotnet tool install -g dotnet-runtimeinfo
dotnet-runtimeinfo
五运行时和类库的提升1. RyuJIT的代码质量提升可以参考这个链接Performance Improvements in RyuJIT in .NET Core and .NET Framework2. GC垃圾回收Card mark stealing – dotnet/coreclr #25986 – Server GC (on different threads) can now work-steal while marking gen0/1 objects held live by older generation objects. This means that ephemeral GC pauses are shorter for scenarios where some GC threads took much longer to mark than others. ServerGC 中标记阶段的耗时更短了Introducing Pinned Object Heap – dotnet/runtime #32283 — Adds the Pinned Object Heap (POH). This new heap (a peer to the Large Object Heap (LOH)) will allow the GC to manage pinned objects separately, and as a result avoid the negative effects of pinned objects on the generational heaps. 新增固定对象堆POH。此新堆与大对象堆LOH对等将允许GC单独管理固定对象从而避免固定对象对堆的负面影响。Allow allocating large object from free list while background sweeping SOH — Enabled LOH allocations using the free list while BGC is sweeping SOH. Previously this was only using end of segment space on LOH. This allowed for better heap usage.允许在后台扫描SOH时从空闲列表中分配大对象Background GC suspension fixes – dotnet/coreclr #27729 — Suspension fixes to reduce time for both BGC and user threads to be suspended. This reduces the total time it takes to suspend managed threads before a GC can happen. dotnet/coreclr #27578 also contributes to the same outcome. 挂起修复程序可减少BGC和用户线程挂起的时间。这样可以减少发生GC之前挂起托管线程所需的总时间。Fix named cgroup handling in docker — Added support to read limits from named cgroups. Previously we only read from the global one. 修复了docker中命名cgroup处理的问题—添加了对从命名cgroups读取限制的支持Optimize vectorized sorting – dotnet/runtime #37159 — vectorized mark list sorting in GC which reduces the ephemeral GC pause time (also dotnet/runtime #40613). GC中的矢量化标记列表排序减少了短暂的GC暂停时间Generational aware analysis – dotnet/runtime #40322 — generational aware analysis that allows you to determine what old generation objects hold on to younger generation objects thus making them survive and contribute to ephemeral GC pause time.GC代感知分析能够确定哪些旧世代对象保留在年轻代对象上从而使它们得以生存并有助于短暂的GC暂停时间。Optimize decommitting GC heap memory pages – dotnet/runtime #35896 — optimized decommit, much better decommit logic and for Server GC took decommit completely out of the “stop the world” phase which reduced blocking GC pause time.优化了取消授权更好的取消授权逻辑对于Server GC完全取消了“停止一切”阶段的授权从而减少了阻塞GC的暂停时间整体总结一下Server GC延迟更低了CPU消耗更少、性能更好了。3. Windows Arm64的支持.NET应用程序现在可以在Windows Arm64上本机运行。在.NET Core 3.0中添加的对Linux Arm64的支持对glibc和musl的支持。使用.NET 5.0可以在Windows Arm64设备例如Surface Pro X上开发和运行应用程序。也可以通过x86仿真在Windows Arm64上运行.NET Core和.NET Framework应用程序。但是本机运行Arm64具有更好的性能。同时.NET 5.0 SDK当前在Windows Arm64上不包含Windows桌面组件-Windows窗体和WPF。Windows Arm64上支持SDK控制台和ASP.NET Core应用程序但Windows桌面组件不支持。4. Arm64性能优化.NET 5.0 中主要针对Arm64平台做了以下优化调整Arm64的JIT优化示例1启用并利用Arm64硬件内部函数示例2。调整Arm64库中对性能至关重要的算法示例3。更多详细信息请参见在.NET 5.0中提高Arm64性能。5. P95 延迟改进Stack Overflow的一位工程师Nick Craver最近分享了他们升级.NET Core后对延迟的改进问题页面的展现时间中值从大约21毫秒由于GC而有所增加降至约15毫秒。第95个百分位数从〜40ms下降到〜30ms相同测量。第99位从〜60ms降至〜45ms。.NET项目组的解读是这样的固定对象一直是GC性能的长期挑战因为它们会加速或导致内存碎片。.NET 5.0为固定对象添加了新的GC堆。该固定对象堆是基于这样的假设以空间换时间他们的存在会导致不相称的性能挑战极少数固定的对象。将固定的对象尤其是由.NET库作为实现细节创建的对象移动到唯一的区域是有意义的而垃圾回收代的GC堆几乎没有或没有固定的对象因此具有更高的性能。6. 分层编译性能改进关于分层编译大家可以参考这个连接https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1在.NET 5.0中对分层编译进行了两项重大改进。下面这2段有点复杂也比较晦涩分层编译的主要机制是调用计数。一旦某个方法被调用了n次运行时就会要求JIT以更高的质量重新编译该方法。从最早的性能分析中发现采用计数机制太慢但是没有找到解决该问题的直接方法。.NET 5.0中改进了分层JIT编译所使用的调用计数机制以平滑启动期间的性能。在过去的发行版中已经发现在进程生命周期的前10到15秒钟内性能会发生不可预测的变化主要是针对Web服务器。目前应该已经解决了。另一个性能挑战是对具有循环的方法使用分层编译。根本的问题是您可以使用带有循环多次的循环的冷方法仅调用一次或几次$ lt; n。我们称这种病理情况为“冷方法”。热循环”。可以想象Main应用程序的方法会发生这种情况。结果默认情况下我们禁用了带循环方法的分层编译。相反使应用程序可以选择使用带循环的分层编译。在某些情况下看到了个位数的高性能改进后PowerShell就是选择执行此操作的应用程序。为了更好地解决循环问题.NET 实现了栈上替换OSR。这类似于Java虚拟机具有的同名功能。OSR允许在方法执行过程中重新编译当前正在运行的方法执行的代码而这些方法是“堆栈上”活动的。该功能目前处于试验和选择启用状态并且仅在x64上可用。要使用OSR必须启用多个功能。目前.NET 5.0中没有启用OSR这个功能尚未决定在生产环境中是否启用所以这个技术点了解即可。7. JSON序列化 System.Text.Json.NET 5.0 对System.Text.Json进行了显着改进以提高性能和可靠性同时API尽可能地和Newtonsoft.Json类似。它还包括对将JSON对象反序列化对record类型的支持。同时微软提供了System.Text.Json替换Newtonsoft.Json的迁移指南。该指南详细阐明了这两个API之间的关系。如何从 Newtonsoft.Json 迁移到 System.Text.JsonJsonSerializer.NET 5.0中的性能显着提高。Stephen Toub在.NET 5中的性能改进中介绍了一些JsonSerializer改进。文中蓝色标注文档链接如下Performance Improvements in RyuJIT in .NET Core and .NET Frameworkhttps://devblogs.microsoft.com/dotnet/performance-improvements-in-ryujit-in-net-core-and-net-framework?WT.mc_idDT-MVP-5003918Card mark stealing – dotnet/coreclr #25986https://github.com/dotnet/coreclr/pull/25986Introducing Pinned Object Heap – dotnet/runtime #32283https://github.com/dotnet/runtime/pull/32283Allow allocating large object from free list while background sweeping SOHhttps://github.com/dotnet/runtime/pull/2103Background GC suspension fixes – dotnet/coreclr #27729https://github.com/dotnet/coreclr/pull/27729Fix named cgroup handling in dockerhttps://github.com/dotnet/runtime/pull/980Optimize vectorized sorting – dotnet/runtime #37159https://github.com/dotnet/runtime/pull/37159Generational aware analysis – dotnet/runtime #40322https://github.com/dotnet/runtime/pull/40332dotnet/runtime #40613https://github.com/dotnet/runtime/pull/40613Optimize decommitting GC heap memory pages – dotnet/runtime #35896https://github.com/dotnet/runtime/pull/35896示例1https://github.com/dotnet/runtime/pull/35675示例2https://github.com/dotnet/runtime/pull/34486示例3https://github.com/dotnet/runtime/issues/34198在.NET 5.0中提高Arm64性能https://github.com/dotnet/runtime/issues/35853如何从 Newtonsoft.Json 迁移到 System.Text.Jsonhttps://docs.microsoft.com/zh-cn/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to?pivotsdotnet-5-0WT.mc_idDT-MVP-5003918JsonSerializer改进https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/#json?WT.mc_idDT-MVP-5003918六应用程序部署应用程序开发完成后根据实际的需要可能会部署到Web服务器云服务或客户端计算机或者使用Azure DevOps或GitHub Actions之类的服务进行CI/CD。.NET 5.0专注于改善单个文件应用程序减小docker多阶段构建的容器大小并为使用.NET Core部署ClickOnce应用程序提供更好的支持。1. 容器与容器的交互协作非常重要。这个版本中添加了OpenTelemetry支持可以从应用程序中捕获分布式跟踪和指标。dotnet-monitor是一个新工具可以作为从.NET进程访问诊断信息的主要工具。特别是我们已经开始构建dotnet-monitor的容器变体您可以将其用作应用程序sidecar。同时.NET项目组正在构建dotnet / tye以提高微服务开发人员在开发和部署到Kubernetes环境中的效率。.NET运行时现在支持cgroup v2这个API预计将在2020年以后成为与容器相关的重要API。Docker当前使用cgroup v1.NET已支持。相比之下cgroup v2比cgroup v1更简单更有效且更安全。.NET 5.0将在cgroup v2环境中正常工作。除了Nano Server微软还将发布Windows Server Core映像努力减小Windows Server Core映像的大小。更小的体积、更低的成本、更快的启动性能。.NET 5.0中将SDK映像重新建立在ASP.NET映像之上而不是buildpack-deps这样可以显着减小在多阶段构建方案中提取的聚合映像的大小。2. 单文件应用 单个文件应用程序作为单个文件发布和部署。该应用程序及其依赖项都包含在该文件中。当应用程序运行时依赖项直接从该文件加载到内存中不影响性能。在.NET 5.0中单个文件应用程序主要集中在Linux上。它们可以是框架相关的也可以是独立的。依赖于全局安装的.NET运行时依赖于框架的单个文件应用程序可能很小。自包含的单文件应用程序较大由于带有运行时但不需要作为安装前步骤就安装.NET运行时因此可以正常工作。通常依赖框架对开发和企业环境有利而对于ISV独立包含通常是更好的选择。.NET Core 3.1制作了一个单文件应用程序版本。它将二进制文件打包到一个文件中以进行部署然后将这些文件解压缩到一个临时目录中以加载并执行它们。在某些情况下这种方法会更好但是希望为5.0构建的解决方案将是首选并且会受到欢迎。 可以使用以下命令来生成单文件应用程序3. ClickOnce ClickOnce一直是流行的.NET部署选项历史也比较悠久了。.NET Core 3.1和.NET 5.0 Windows应用程序现在都已经支持。 以上是.NET 5.0 发布后的技术梳理和整理.NET 5.0作为.NET技术栈上近几年一个重量级的里程碑是微软.NET技术 All in one 统一平台的第一个版本。微软从.NET 5.0 Preview 1就开始在自己的网站上大规模使用(Bing.com、dot.net已升级并运行了数个月)同时早期的.NET Core版本可以直接升级到.NET 5.0. 所以大家可以放心使用的也推荐大家逐步迁移升级到.NET 5.0.参考链接https://devblogs.microsoft.com/dotnet/announcing-net-5-0?WT.mc_idDT-MVP-5003918https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/#json?WT.mc_idDT-MVP-5003918https://blogs.windows.com/windowsdeveloper/2020/11/10/announcing-c-winrt-version-1-0-with-the-net-5-ga-release?WT.mc_idDT-MVP-5003918
