极速网站建设哪家好,虫部落导航网站怎么做,建网站有什么要注意的,网站开发 入门 pdf点击上方蓝字关注我们#xff08;本文阅读时间#xff1a;15分钟).NET 6 继续与大家相约周日啦。本篇文章将介绍#xff1a;单文件应用、IL 修整、System.Text.Json、源代码构建、库AIP的相关攻略。 单文件应用 在 .NET 6中#xff0c;已为 Windows 和 macOS 启用内存中单文… 点击上方蓝字关注我们本文阅读时间15分钟).NET 6 继续与大家相约周日啦。本篇文章将介绍单文件应用、IL 修整、System.Text.Json、源代码构建、库AIP的相关攻略。 单文件应用 在 .NET 6中已为 Windows 和 macOS 启用内存中单文件应用程序。在 .NET 5 中这种部署类型仅限于 Linux。您现在可以为所有受支持的操作系统发布作为单个文件部署和启动的单文件二进制文件。单文件应用不再将任何核心运行时程序集提取到临时目录。这种扩展功能基于称为“超级主机”的构建块。“apphost” 是在非单文件情况下启动应用程序的可执行文件例如 myapp.exe或./myapp. Apphost 包含用于查找运行时、加载它并使用该运行时启动您的应用程序的代码。Superhost 仍然执行其中一些任务但使用所有 CoreCLR 本机二进制文件的静态链接副本。静态链接是我们用来实现单一文件体验的方法。本机依赖项如 NuGet 包附带的是单文件嵌入的显着例外。默认情况下它们不包含在单个文件中。例如WPF 本机依赖项不是超级主机的一部分因此会在单文件应用程序之外产生其他文件。您可以使用该设置 IncludeNativeLibrariesForSelfExtract 嵌入和提取本机依赖项。▌静态分析我们改进了单文件分析器以允许自定义警告。如果您的 API 在单文件发布中不起作用您现在可以使用[RequiresAssemblyFiles]属性对其进行标记如果启用了分析器则会出现警告。添加该属性还将使方法中与单个文件相关的所有警告静音因此您可以使用该警告将警告向上传播到您的公共 API。当 PublishSingleFile 设置为 true 时会自动为 exe 项目启用单文件分析器但您也可以通过将 EnableSingleFileAnalysis 设置为 true 来为任何项目启用它。如果您想支持将库作为单个文件应用程序的一部分这将很有帮助。在 .NET 5 中我们为单文件包中行为不同的 Assembly.Location 和一些其他 API 添加了警告。▌压缩单文件包现在支持压缩可以通过将属性设置 EnableCompressionInSingleFile为true. 在运行时文件会根据需要解压缩到内存中。压缩可以为某些场景节省大量空间。让我们看一下与 NuGet 包资源管理器一起使用的单个文件发布带压缩和不带压缩。无压缩172 MB压缩71.6 MB压缩会显着增加应用程序的启动时间尤其是在 Unix 平台上。Unix 平台有一个不能用于压缩的无拷贝快速启动路径。您应该在启用压缩后测试您的应用程序看看额外的启动成本是否可以接受。▌单文件调试目前只能使用平台调试器如 WinDBG来调试单文件应用程序。我们正在考虑使用更高版本的 Visual Studio 2022 添加 Visual Studio 调试。▌macOS 上的单文件签名单文件应用程序现在满足 macOS 上的 Apple 公证和签名要求。具体更改与我们根据离散文件布局构建单文件应用程序的方式有关。Apple 开始对macOS Catalina实施新的签名和公证要求。我们一直在与 Apple 密切合作以了解需求并寻找使 .NET 等开发平台能够在该环境中正常工作的解决方案。我们已经进行了产品更改并记录了用户工作流程以满足 Apple 在最近几个 .NET 版本中的要求。剩下的差距之一是单文件签名这是在 macOS 上分发 .NET 应用程序的要求包括在 macOS 商店中。IL 修整该团队一直致力于为多个版本进行 IL 修整。.NET 6 代表了这一旅程向前迈出的重要一步。我们一直在努力使更激进的修剪模式安全且可预测因此有信心将其设为默认模式。TrimModelink 以前是可选功能现在是默认功能。我们有一个三管齐下的修剪策略提高平台的修剪能力。对平台进行注释以提供更好的警告并使其他人也能这样做。在此基础上让默认的修剪模式更具侵略性以便让应用程序变小。由于使用未注释反射的应用程序的结果不可靠修剪之前一直处于预览状态。有了修剪警告体验现在应该是可预测的。没有修剪警告的应用程序应该正确修剪并且在运行时观察到行为没有变化。目前只有核心的 .NET 库已经完全注解了修剪但我们希望看到生态系统注释修剪并兼容修剪。▌减小应用程序大小让我们使用SDK 工具之一的crossgen来看看这个修剪改进。它可以通过几个修剪警告进行修剪crossgen 团队能够解决。首先让我们看一下将 crossgen 发布为一个独立的应用程序而无需修剪。它是 80 MB包括 .NET 运行时和所有库。然后我们可以尝试现在是旧版.NET 5 默认修剪模式copyused. 结果降至 55 MB。新的 .NET 6 默认修剪模式link将独立文件大小进一步降低到 36MB。我们希望新的link修剪模式能更好地与修剪的期望保持一致显着节省和可预测的结果。默认启用警告修剪警告告诉您修剪可能会删除运行时使用的代码的地方。这些警告以前默认禁用因为警告非常嘈杂主要是由于 .NET 平台没有参与修剪作为第一类场景。我们对大部分 .NET 库进行了注释以便它们产生准确的修剪警告。因此我们觉得是时候默认启用修剪警告了。ASP.NET Core 和 Windows 桌面运行时库尚未注释。我们计划接下来注释 ASP.NET 服务组件在 .NET 6 之后。我们希望看到社区在 .NET 6 发布后对 NuGet 库进行注释。您可以通过设置SuppressTrimAnalysisWarnings为true来禁用警告。更多信息修剪警告修剪介绍准备 .NET 库以进行修剪与本机 AOT 共享我们也为Native AOT 实验实现了相同的修剪警告这应该会以几乎相同的方式改善 Native AOT 编译体验。数学我们显着改进了数学 API。社区中的一些人已经在享受这些改进。面向性能的 APISystem.Math 中添加了面向性能的数学 API。如果底层硬件支持它们的实现是硬件加速的。新 APISinCos 用于同时计算 Sin 和 Cos。ReciprocalEstimate 用于计算 1 / x的近似值。ReciprocalSqrtEstimate 用于计算1 / Sqrt(x) 的近似值。新的重载ClampDivRemMin 和 Max 支持 nint 和 nuint。Abs 和 Sign支持 nint。DivRem 变体返回 tuple。性能改进ScaleB被移植到 C# 导致调用速度提高了 93%。感谢亚历克斯·科文顿。大整数性能改进了从十进制和十六进制字符串中解析 BigIntegers 。我们看到了高达 89% 的改进如下图所示越低越好。感谢约瑟夫·达席尔瓦。▌ComplexAPI 现在注释为 readonly现在对各种 API 进行了注释System.Numerics.Complexreadonly 以确保不会对readonly值或传递的值进行复制 in。归功于 hrrrrustic 。▌BitConverter现在支持浮点到无符号整数位广播BitConverter 现在支持 DoubleToUInt64Bits, HalfToUInt16Bits, SingleToUInt32Bits, UInt16BitsToHalf, UInt32BitsToSingle, 和UInt64BitsToDouble. 这应该使得在需要时更容易进行浮点位操作。归功于 Michal Petryka 。▌BitOperations支持附加功能BitOperations现在支持IsPow2,RoundUpToPowerOf2和提供nint/nuint重载现有函数。感谢约翰凯利、霍耀源和罗宾林德纳。▌VectorT, Vector2, Vector3, 和Vector4改进VectorT 现在支持C# 9 中添加的原始类型nint和nuint原始类型。例如此更改应该可以更简单地使用带有指针或平台相关长度类型的 SIMD 指令。VectorT 现在支持一种Sum方法来简化计算向量中所有元素的“水平和”的需要。归功于伊万兹拉塔诺夫。VectorT 现在支持一种通用方法AsTFrom, TTo来简化在具体类型未知的通用上下文中处理向量。感谢霍耀源重载支持SpanT已添加到Vector2、Vector3和Vector4以改善需要加载或存储矢量类型时的体验。▌更好地解析标准数字格式我们改进了标准数字类型的解析器特别是.ToString和.TryFormatParse。他们现在将理解对精度 99 位小数的要求并将为那么多位数提供准确的结果。此外解析器现在更好地支持方法中的尾随零。以下示例演示了之前和之后的行为。32.ToString(C100)-C132.NET 6$32.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.NET 5我们在格式化代码中人为限制只能处理 99 的精度。对于精度 100我们改为将输入解释为自定义格式。32.ToString(H99)- 扔一个FormatException.NET 6抛出 FormatException。这是正确的行为但在这里调用它是为了与下一个示例进行对比。32.ToString(H100)-H132.NET 6抛出 FormatException。.NET 5H是无效的格式说明符。所以我们应该抛出一个FormatException. 相反我们将精度 100 解释为自定义格式的错误行为意味着我们返回了错误的值。double.Parse(9007199254740997.0)-9007199254740998.NET 6 9007199254740996。.NET 59007199254740997.0不能完全以 IEEE 754 格式表示。使用我们当前的舍入方案正确的返回值应该是9007199254740996. 但是输入的最后一部分迫使解析器错误地舍入结果并返回 .09007199254740998。System.Text.JsonSystem.Text.Json 提供多种高性能 API 用于处理 JSON 文档。在过去的几个版本中我们添加了新功能以进一步提高 JSON 处理性能并减轻对希望从NewtonSoft.Json迁移的人的阻碍。此版本包括在该路径上的继续并且在性能方面向前迈出了一大步特别是在序列化程序源生成器方面。▌JsonSerializer 源生成注意使用 .NET 6 RC1 或更早版本的源代码生成的应用程序应重新编译。几乎所有 .NET 序列化程序的支柱都是反射。反射对于某些场景来说是一种很好的能力但不能作为高性能云原生应用程序通常反序列化和处理大量 JSON 文档的基础。反射是启动、内存使用和程序集修整的问题。运行时反射的替代方法是编译时源代码生成。在 .NET 6 中我们包含一个新的源代码生成器作为System.Text.Json. JSON 源代码生成器可以与多种方式结合使用JsonSerializer并且可以通过多种方式进行配置。它可以提供以下好处• 减少启动时间• 提高序列化吞吐量• 减少私有内存使用• 删除运行时使用System.Reflection 和System.Reflection.Emit• IL 修整兼容性默认情况下JSON 源生成器为给定的可序列化类型发出序列化逻辑。JsonSerializer通过生成直接使用的源代码这提供了比使用现有方法更高的性能Utf8JsonWriter。简而言之源代码生成器提供了一种在编译时为您提供不同实现的方法以使运行时体验更好。给定一个简单的类型namespace Test
{internal class JsonMessage{public string Message { get; set; }}
}源生成器可以配置为为示例 JsonMessage 类型的实例生成序列化逻辑。请注意类名JsonContext是任意的。您可以为生成的源使用所需的任何类名。using System.Text.Json.Serialization;namespace Test
{[JsonSerializable(typeof(JsonMessage)]internal partial class JsonContext : JsonSerializerContext{}
}使用此模式的序列化程序调用可能类似于以下示例。此示例提供了可能的最佳性能。using MemoryStream ms new();
using Utf8JsonWriter writer new(ms);JsonSerializer.Serialize(jsonMessage, JsonContext.Default.JsonMessage);
writer.Flush();// Writer contains:
// {Message:Hello, world!}最快和最优化的源代码生成模式——基于Utf8JsonWriter——目前仅可用于序列化。Utf8JsonReader根据您的反馈将来可能会提供对反序列化的类似支持。源生成器还发出类型元数据初始化逻辑这也有利于反序列化。JsonMessage要反序列化使用预生成类型元数据的实例您可以执行以下操作JsonSerializer.Deserialize(json, JsonContext.Default.JsonMessage);▌JsonSerializer 支持 IAsyncEnumerable您现在可以使用System.Text.Json 反序列化IAsyncEnumerableTJSON数组。以下示例使用流作为任何异步数据源的表示。源可以是本地计算机上的文件也可以是数据库查询或 Web 服务 API 调用的结果。JsonSerializer.SerializeAsync已更新以识别并为IAsyncEnumerable值提供特殊处理。using System;
using System.Collections.Generic;
using System.IO;
using System.Text.Json;static async IAsyncEnumerableint PrintNumbers(int n)
{for (int i 0; i n; i) yield return i;
}using Stream stream Console.OpenStandardOutput();
var data new { Data PrintNumbers(3) };
await JsonSerializer.SerializeAsync(stream, data); // prints {Data:[0,1,2]}IAsyncEnumerable 仅使用异步序列化方法支持值。尝试使用同步方法进行序列化将导致NotSupportedException被抛出。流式反序列化需要一个新的 API 来返回 I AsyncEnumerableT. 我们为此添加了JsonSerializer.DeserializeAsyncEnumerable方法您可以在以下示例中看到。using System;
using System.IO;
using System.Text;
using System.Text.Json;var stream new MemoryStream(Encoding.UTF8.GetBytes([0,1,2,3,4]));
await foreach (int item in JsonSerializer.DeserializeAsyncEnumerableint(stream))
{Console.WriteLine(item);
}此示例将按需反序列化元素并且在使用特别大的数据流时非常有用。它仅支持从根级 JSON 数组读取尽管将来可能会根据反馈放宽。现有 DeserializeAsync 方法名义上支持 I AsyncEnumerableT但在其非流方法签名的范围内。它必须将最终结果作为单个值返回如以下示例所示。using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Text.Json;var stream new MemoryStream(Encoding.UTF8.GetBytes({Data:[0,1,2,3,4]}));
var result await JsonSerializer.DeserializeAsyncMyPoco(stream);
await foreach (int item in result.Data)
{Console.WriteLine(item);
}public class MyPoco
{public IAsyncEnumerableint Data { get; set; }
}在此示例中反序列化器将 IAsyncEnumerable 在返回反序列化对象之前缓冲内存中的所有内容。这是因为反序列化器需要在返回结果之前消耗整个 JSON 值。▌System.Text.Json可写 DOM 功能可写 JSON DOM特性为 System.Text.Json添加了一个新的简单且高性能的编程模型。这个新的 API 很有吸引力因为它避免了需要强类型的序列化合约并且与现有的 JsonDocument类型相比DOM 是可变的。这个新的 API 有以下好处在使用POCO类型是不可能或不希望的情况下或者当 JSON 模式不固定且必须检查的情况下序列化的轻量级替代方案。启用对大树子集的有效修改。例如可以有效地导航到大型 JSON 树的子部分并从该子部分读取数组或反序列化 POCO。LINQ 也可以与它一起使用。以下示例演示了新的编程模型。// Parse a JSON objectJsonNode jNode JsonNode.Parse({MyProperty:42});int value (int)jNode[MyProperty];Debug.Assert(value 42);// orvalue jNode[MyProperty].GetValueint();Debug.Assert(value 42);// Parse a JSON arrayjNode JsonNode.Parse([10,11,12]);value (int)jNode[1];Debug.Assert(value 11);// orvalue jNode[1].GetValueint();Debug.Assert(value 11);// Create a new JsonObject using object initializers and array paramsvar jObject new JsonObject{[MyChildObject] new JsonObject{[MyProperty] Hello,[MyArray] new JsonArray(10, 11, 12)}};// Obtain the JSON from the new JsonObjectstring json jObject.ToJsonString();Console.WriteLine(json); // {MyChildObject:{MyProperty:Hello,MyArray:[10,11,12]}}// Indexers for property names and array elements are supported and can be chained
Debug.Assert(jObject[MyChildObject][MyArray][1].GetValueint() 11);▌ReferenceHandler.IgnoreCyclesJsonSerializer(System.Text.Json)现在支持在序列化对象图时忽略循环的能力。该ReferenceHandler.IgnoreCycles选项具有与 Newtonsoft.Json ReferenceLoopHandling.Ignore类似的行为。一个关键区别是 System.Text.Json 实现用null JSON 标记替换引用循环而不是忽略对象引用。您可以在以下示例中看到ReferenceHandler.IgnoreCycles 的行为。在这种情况下该Next属性被序列化为null因为否则它会创建一个循环。class Node
{public string Description { get; set; }public object Next { get; set; }
}void Test()
{var node new Node { Description Node 1 };node.Next node;var opts new JsonSerializerOptions { ReferenceHandler ReferenceHandler.IgnoreCycles };string json JsonSerializer.Serialize(node, opts);Console.WriteLine(json); // Prints {Description:Node 1,Next:null}
}源代码构建通过源代码构建您只需几个命令即可在您自己的计算机上从源代码构建 .NET SDK 。让我解释一下为什么这个项目很重要。源代码构建是一个场景也是我们在发布 .NET Core 1.0 之前一直与 Red Hat 合作开发的基础架构。几年后我们非常接近于交付它的全自动版本。对于 Red Hat Enterprise Linux (RHEL) .NET 用户来说这个功能很重要。Red Hat 告诉我们.NET 已经发展成为其生态系统的重要开发者平台。好的Linux 发行版的黄金标准是使用作为发行版存档一部分的编译器和工具链构建开源代码。这适用于 .NET 运行时用 C 编写但不适用于任何用 C# 编写的代码。对于 C# 代码我们使用两遍构建机制来满足发行版要求。这有点复杂但了解流程很重要。Red Hat 使用 .NET SDK (#1) 的 Microsoft 二进制构建来构建 .NET SDK 源代码以生成 SDK (#2) 的纯开源二进制构建。之后使用这个新版本的 SDK (#2) 再次构建相同的 SDK 源代码以生成可证明的开源 SDK (#3)。.NET SDK (#3) 的最终二进制版本随后可供 RHEL 用户使用。之后Red Hat 可以使用相同的 SDK (#3) 来构建新的 .NET 版本而不再需要使用 Microsoft SDK 来构建每月更新。这个过程可能令人惊讶和困惑。开源发行版需要通过开源工具构建。此模式确保不需要 Microsoft 构建的 SDK无论是有意还是无意。作为开发者平台包含在发行版中的门槛比仅使用兼容许可证的门槛更高。源代码构建项目使 .NET 能够满足该标准。源代码构建的可交付成果是源代码压缩包。源 tarball 包含 SDK 的所有源对于给定版本。从那里红帽或其他组织可以构建自己的 SDK 版本。Red Hat 政策要求使用内置源工具链来生成二进制 tar 球这就是他们使用两遍方法的原因。但是源代码构建本身不需要这种两遍方法。在 Linux 生态系统中给定组件同时拥有源和二进制包或 tarball 是很常见的。我们已经有了可用的二进制 tarball现在也有了源 tarball。这使得 .NET 与标准组件模式相匹配。.NET 6 的重大改进是源 tarball 现在是我们构建的产品。它过去需要大量的人工来制作这也导致将源 tarball 交付给 Red Hat 的延迟很长。双方都对此不满意。在这个项目上我们与红帽密切合作五年多。它的成功在很大程度上要归功于我们有幸与之共事的优秀红帽工程师的努力。其他发行版和组织已经并将从他们的努力中受益。附带说明一下源代码构建是朝着可重现构建迈出的一大步我们也坚信这一点。.NET SDK 和 C# 编译器具有重要的可重现构建功能。库 API除了已经涵盖的 API 之外还添加了以下 API。▌WebSocket 压缩压缩对于通过网络传输的任何数据都很重要。WebSockets 现在启用压缩。我们使用了WebSockets 的扩展permessage-deflate实现RFC 7692。它允许使用该DEFLATE算法压缩 WebSockets 消息负载。此功能是 GitHub 上 Networking 的主要用户请求之一。与加密一起使用的压缩可能会导致攻击例如CRIME和BREACH。这意味着不能在单个压缩上下文中将秘密与用户生成的数据一起发送否则可以提取该秘密。为了让用户注意到这些影响并帮助他们权衡风险我们将其中一个关键 API 命名为DangerousDeflateOptions。我们还添加了关闭特定消息压缩的功能因此如果用户想要发送秘密他们可以在不压缩的情况下安全地执行此操作。禁用压缩时 WebSocket的内存占用减少了约 27%。从客户端启用压缩很容易如下例所示。但是请记住服务器可以协商设置例如请求更小的窗口或完全拒绝压缩。var cws new ClientWebSocket();
cws.Options.DangerousDeflateOptions new WebSocketDeflateOptions()
{ClientMaxWindowBits 10,ServerMaxWindowBits 10
};还添加了对 ASP.NET Core 的 WebSocket 压缩支持。归功于伊万兹拉塔诺夫。▌Socks 代理支持SOCKS是一种代理服务器实现可以处理任何 TCP 或 UDP 流量使其成为一个非常通用的系统。这是一个长期存在的社区请求已添加到 .NET 6中。此更改增加了对 Socks4、Socks4a 和 Socks5 的支持。例如它可以通过 SSH 测试外部连接或连接到 Tor 网络。该类WebProxy现在接受socks方案如以下示例所示。var handler new HttpClientHandler
{Proxy new WebProxy(socks5://127.0.0.1, 9050)
};
var httpClient new HttpClient(handler);归功于 Huo yaoyuan。▌Microsoft.Extensions.Hosting — 配置主机选项 API我们在 IHostBuilder 上添加了一个新的 ConfigureHostOptions API以简化应用程序设置例如配置关闭超时using HostBuilder host new().ConfigureHostOptions(o {o.ShutdownTimeout TimeSpan.FromMinutes(10);}).Build();host.Run();在 .NET 5 中配置主机选项有点复杂using HostBuilder host new().ConfigureServices(services {services.ConfigureHostOptions(o {o.ShutdownTimeout TimeSpan.FromMinutes(10);});}).Build();host.Run();▌Microsoft.Extensions.DependencyInjection — CreateAsyncScope APICreateAsyncScope 创建API是为了处理服务的处置 IAsyncDisposable。以前您可能已经注意到处置 IAsyncDisposable 服务提供者可能会引发 InvalidOperationException 异常。以下示例演示了新模式CreateAsyncScope 用于启用 using 语句的安全使用。await using (var scope provider.CreateAsyncScope())
{var foo scope.ServiceProvider.GetRequiredServiceFoo();
}以下示例演示了现有的问题案例using System;
using System.Threading.Tasks;
using Microsoft.Extensions.DependencyInjection;await using var provider new ServiceCollection().AddScopedFoo().BuildServiceProvider();// This using can throw InvalidOperationException
using (var scope provider.CreateScope())
{var foo scope.ServiceProvider.GetRequiredServiceFoo();
}class Foo : IAsyncDisposable
{public ValueTask DisposeAsync() default;
}以下模式是先前建议的避免异常的解决方法。不再需要它。var scope provider.CreateScope();
var foo scope.ServiceProvider.GetRequiredServiceFoo();
await ((IAsyncDisposable)scope).DisposeAsync();感谢 Martin Björkström 。▌Microsoft.Extensions.Logging — 编译时源生成器.NET 6引入了LoggerMessageAttribute类型. 此属性是Microsoft.Extensions.Logging 命名空间的一部分使用时它会源生成高性能日志记录 API。源生成日志支持旨在为现代 .NET 应用程序提供高度可用和高性能的日志解决方案。自动生成的源代码依赖于 ILogger 接口和 LoggerMessage.Define功能。LoggerMessageAttribute 源生成器在用于 partial 日志记录方法时触发。当被触发时它要么能够自动生成 partial 它正在装饰的方法的实现要么生成编译时诊断并提供有关正确使用的提示。编译时日志记录解决方案在运行时通常比现有的日志记录方法快得多。它通过最大限度地消除装箱、临时分配和副本来实现这一点。与直接手动使用 LoggerMessage.Define API 相比有以下好处更短更简单的语法声明性属性使用而不是编码样板。引导式开发人员体验生成器发出警告以帮助开发人员做正确的事情。支持任意数量的日志记录参数。LoggerMessage.Define 最多支持六个。支持动态日志级别。这是 LoggerMessage.Define 单独不可能的。要使用 LoggerMessageAttribute消费类和方法需要是 partial。代码生成器在编译时触发并生成 partial 方法的实现。public static partial class Log
{[LoggerMessage(EventId 0, Level LogLevel.Critical, Message Could not open socket to {hostName})]public static partial void CouldNotOpenSocket(ILogger logger, string hostName);
}在前面的示例中日志记录方法是 static并且在属性定义中指定了日志级别。在静态上下文中使用属性时ILogger 需要实例作为参数。您也可以选择在非静态上下文中使用该属性。有关更多示例和使用场景请访问编译时日志记录源生成器文档。▌System.Linq — 可枚举的支持 Index 和 Range 参数该 Enumerable.ElementAt 方法现在接受来自可枚举末尾的索引如以下示例所示。Enumerable.Range(1, 10).ElementAt(^2); // returns 9添加了一个 Enumerable.Take 接受 Range 参数的重载。它简化了对可枚举序列的切片source.Take(..3)代替source.Take(3)source.Take(3..)代替source.Skip(3)source.Take(2..7)代替source.Take(7).Skip(2)source.Take(^3..)代替source.TakeLast(3)source.Take(..^3)代替source.SkipLast(3)source.Take(^7..^3)而不是.source.TakeLast(7).SkipLast(3)感谢dixin 。▌System.Linq —TryGetNonEnumeratedCount该 TryGetNonEnumeratedCount 方法尝试在不强制枚举的情况下获取源可枚举的计数。这种方法在枚举之前预分配缓冲区很有用的场景中很有用如下面的示例所示。ListT buffer source.TryGetNonEnumeratedCount(out int count) ? new ListT(capacity: count) : new ListT();
foreach (T item in source)
{buffer.Add(item);
}TryGetNonEnumeratedCount 检查实现 ICollection/ ICollectionT或利用Linq 采用的一些内部优化的源。▌System.Linq — DistinctBy/ UnionBy/ IntersectBy/ExceptBy新变体已添加到允许使用键选择器函数指定相等性的集合操作中如下例所示。Enumerable.Range(1, 20).DistinctBy(x x % 3); // {1, 2, 3}var first new (string Name, int Age)[] { (Francis, 20), (Lindsey, 30), (Ashley, 40) };
var second new (string Name, int Age)[] { (Claire, 30), (Pat, 30), (Drew, 33) };
first.UnionBy(second, person person.Age); // { (Francis, 20), (Lindsey, 30), (Ashley, 40), (Drew, 33) }▌System.Linq - MaxBy/MinByMaxBy 和 MinBy 方法允许使用键选择器查找最大或最小元素如下例所示。var people new (string Name, int Age)[] { (Francis, 20), (Lindsey, 30), (Ashley, 40) };
people.MaxBy(person person.Age); // (Ashley, 40)▌System.Linq —ChunkChunk可用于将可枚举的源分块为固定大小的切片如下例所示。IEnumerableint[] chunks Enumerable.Range(0, 10).Chunk(size: 3); // { {0,1,2}, {3,4,5}, {6,7,8}, {9} }归功于罗伯特安德森。▌System.Linq—— //FirstOrDefault 采用默认参数的重载LastOrDefaultSingleOrDefault如果源可枚举为空则现有的 FirstOrDefault /LastOrDefault /SingleOrDefault 方法返回 default(T)。添加了新的重载它们接受在这种情况下返回的默认参数如以下示例所示。 Enumerable.Emptyint().SingleOrDefault(-1); // returns -1感谢 Foxtrek64 。▌System.Linq —Zip 接受三个可枚举的重载Zip方法现在支持组合三个枚举如以下示例所示。var xs Enumerable.Range(1, 10);var ys xs.Select(x x.ToString());var zs xs.Select(x x % 2 0);foreach ((int x, string y, bool z) in Enumerable.Zip(xs,ys,zs)){}归功于 Huo yaoyuan 。▌优先队列PriorityQueueTElement, TPriority(System.Collections.Generic) 是一个新集合可以添加具有值和优先级的新项目。在出队时PriorityQueue 返回具有最低优先级值的元素。您可以认为这个新集合类似于QueueT但每个入队元素都有一个影响出队行为的优先级值。以下示例演示了.PriorityQueuestring, int// creates a priority queue of strings with integer priorities
var pq new PriorityQueuestring, int();// enqueue elements with associated priorities
pq.Enqueue(A, 3);
pq.Enqueue(B, 1);
pq.Enqueue(C, 2);
pq.Enqueue(D, 3);pq.Dequeue(); // returns B
pq.Dequeue(); // returns C
pq.Dequeue(); // either A or D, stability is not guaranteed.归功于 Patryk Golebiowski。精彩攻略欢迎继续转到下篇文章继续阅读哦往期精彩回顾▎.NET 6 攻略大全一▎.NET 6 攻略大全二 了解更多.NET
