各位老铁们，大家好，今天由我来为大家分享asp.net教程下载—asp.net app，以及的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！

• 教程：使用 ASP.NET Core 创建最小的 Web API
• 最小 API 和带控制器的 API 之间的区别
• 最小 API 概述
• 代码示例迁移到 6.0 中的新最小托管模型

SignalR 使用新的Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity将http.long_running标记添加到请求活动。Azure Monitor Application Insights等APM 服务IHttpActivityFeature.Activity使用它来过滤 SignalR 请求以防止创建长时间运行的请求警报。

• 每个连接分配一次HubCallerClients，而不是每个集线器方法调用。
• 避免 SignalR 中的闭包分配DefaultHubDispatcher.Invoke。状态通过参数传递给本地静态函数以避免闭包分配。有关更多信息，请参阅此 GitHub 拉取请求。
• 在服务器到客户端的流式传输中，为每个流而不是每个流项分配一个StreamItemMessage。有关更多信息，请参阅此 GitHub 拉取请求。

Razor 编译器现在基于C# 源代码生成器。源代码生成器在编译期间运行并检查正在编译的内容以生成与项目的其余部分一起编译的附加文件。使用源代码生成器可以简化 Razor 编译器并显着加快构建时间。

Razor 编译器之前使用了一个两步编译过程，该过程生成了一个单独的 Views 程序集，其中包含.cshtml在应用程序中定义的生成的视图和页面（文件）。生成的类型是公共的并且在AspNetCore命名空间下。

更新后的 Razor 编译器将视图和页面类型构建到主项目程序集中。这些类型现在默认生成为AspNetCoreGeneratedDocument命名空间中的内部密封。此更改提高了构建性能，支持单文件部署，并使这些类型能够参与热重载。

有关此更改的更多信息，请参阅GitHub 上的相关公告问题。

进行了许多更改以减少分配并提高整个堆栈的性能：

• 非分配应用程序。使用扩展方法。的新重载app.Use需要传递上下文，next其中保存了使用另一个重载时所需的两个内部每个请求分配。
• 访问HttpRequest.Cookies时减少内存分配。有关更多信息，请参阅此 GitHub 问题。
• 将LoggerMessage.Define用于仅适用于 Windows 的HTTP.sys Web 服务器。该ILogger扩展方法的调用已替换为调用LoggerMessage.Define。
• 将SocketConnection 中的每个连接开销减少约 30%。有关更多信息，请参阅此 GitHub 拉取请求。
• 通过删除泛型类型中的日志记录委托来减少分配。有关更多信息，请参阅此 GitHub 拉取请求。
• 对IHttpRequestFeature、IHttpResponseFeature、IHttpResponseBodyFeature、IRouteValuesFeature和IEndpointFeature等常用功能的更快 GET 访问（约 50%） 。有关更多信息，请参阅此 GitHub 拉取请求。
• 对已知的标头名称使用单个实例字符串，即使它们不在保留的标头块中。使用单个实例字符串有助于防止长期连接中相同字符串的多次重复，例如，在Microsoft.AspNetCore.WebSockets 中。有关更多信息，请参阅此 GitHub 问题。
• 在 Kestrel 中重用HttpProtocol CancellationTokenSource。如果尚未取消令牌，请使用新的CancellationTokenSource.TryReset方法CancellationTokenSource重用令牌。有关更多信息，请参阅此 GitHub 问题和此视频。
• 在Microsoft.AspNetCore.Http RequestCookieCollection 中实现和使用AdaptiveCapacityDictionary以更有效地访问字典。有关更多信息，请参阅此 GitHub 拉取请求。

对于仅偶尔来回发送数据的长时间运行的 TLS 连接，我们在 .NET 6 中显着减少了 ASP.NET Core 应用程序的内存占用。这将有助于提高 WebSocket 服务器等场景的可扩展性。这是可能的，因为System.IO.Pipelines、SslStream和 Kestrel 的许多改进。以下部分详细介绍了有助于减少内存占用的一些改进：

对于建立的每个连接，在 Kestrel 中分配了两个管道：

• 请求的应用程序的传输层。
• 应用层到传输的响应。

通过将System.IO.Pipelines.Pipe的大小从 368 字节缩小到 264 字节（大约减少 28.2%），每个连接节省了 208 字节（每个管道 104 字节）。

SocketSender对象（即SocketAsyncEventArgs 的子类）在运行时约为 350 字节。SocketSender可以将它们池化，而不是为每个连接分配一个新对象。SocketSender对象可以被池化，因为发送通常非常快。池化减少了每个连接的开销。不是为每个连接分配 350 个字节，而是为每个连接分配 350 个字节IOQueue。分配是按队列完成的，以避免争用。我们的具有 5000 个空闲连接的 WebSocket 服务器从分配 ~1.75 MB（350 字节 * 5000）到为SocketSender对象分配 ~2.8 kb（350 字节 * 8）。

无缓冲读取是 ASP.NET Core 中采用的一种技术，用于避免在套接字上没有可用数据时从内存池中租用内存。在此更改之前，我们的具有 5000 个空闲连接的 WebSocket 服务器在不使用 TLS 的情况下需要约 200 MB，而在使用 TLS 的情况下需要约 800 MB。其中一些分配（每个连接 4k）来自 Kestrel，必须在等待SslStream上的读取完成时保留ArrayPool缓冲区。鉴于这些连接处于空闲状态，没有一个读取完成并将其缓冲区返回给，从而迫使分配更多内存。剩下的分配本身就是：4k 缓冲区用于 TLS 握手，32k 缓冲区用于正常读取。在 .NET 6 中，当用户执行零字节读取时ArrayPoolArrayPoolSslStreamSslStream并且它没有可用的数据，在SslStream内部对底层包装流执行零字节读取。在最好的情况下（空闲连接），这些更改会导致每个连接节省 40 Kb，同时仍然允许消费者 (Kestrel) 在数据可用时收到通知，而无需保留任何未使用的缓冲区。

在支持无缓冲读取的情况下SslStream，添加了一个选项来执行零字节读取StreamPipeReader，这是将 a 适配Stream为 a的内部类型PipeReader。在 Kestrel 中， aStreamPipeReader用于将底层证券调整SslStream为 a PipeReader。因此有必要在PipeReader.

甲PipeReader现在可以创建支持零字节读出在任何底层Stream支持零字节读语义（例如，。 SslStream，的NetworkStream使用以下API等）：

.NET 命令行

为了减少堆的碎片，Kestrel 采用了一种技术，它分配 128 KB 的内存块作为其内存池的一部分。然后将这些板进一步划分为 4 KB 的块，供 Kestrel 内部使用。平板必须大于 85 KB 才能强制在大对象堆上进行分配，以尝试阻止 GC 重新定位该数组。然而，随着新一代 GC 的引入，固定对象堆（POH），在平板上分配块不再有意义。Kestrel 现在直接在 POH 上分配块，降低了管理内存池的复杂性。此更改应该更容易执行未来的改进，例如更容易缩小 Kestrel 使用的内存池。

IAsyncDisposable现在可用于控制器、Razor 页面和视图组件。在工厂和激活器的相关接口中添加了异步版本：

• 新方法提供了一个默认接口实现，它委托给同步版本并调用Dispose。
• 实现覆盖默认实现并处理处置IAsyncDisposable实现。
• 该实施有利于IAsyncDisposable在IDisposable当这两个接口来实现。
• 扩展程序必须覆盖包含的新方法以支持 IAsyncDisposable实例。

IAsyncDisposable 与以下人员一起工作时是有益的：

• 异步枚举器，例如，在异步流中。
• 具有资源密集型 I/O 操作要释放的非托管资源。

实现该接口时，使用DisposeAsync方法释放资源。

考虑一个创建和使用Utf8JsonWriter的控制器。Utf8JsonWriter是一个IAsyncDisposable资源：

C＃

IAsyncDisposable必须实施DisposeAsync：

C＃

Vcpkg是 C 和 C++ 库的跨平台命令行包管理器。我们最近添加了一个端口来vcpkg添加CMake对 SignalR C++ 客户端的本机支持。vcpkg也适用于 MSBuild。

当 vcpkg 包含在工具链文件中时，可以使用以下代码段将 SignalR 客户端添加到 CMake 项目中：

.NET 命令行

通过前面的代码片段，SignalR C++ 客户端#include无需任何额外配置即可在项目中使用和使用。有关使用 SignalR C++ 客户端的 C++ 应用程序的完整示例，请参阅halter73/SignalR-Client-Cpp-Sample存储库。

Blazor WebAssembly 应用可以使用为在 WebAssembly 上运行而构建的本机依赖项。有关详细信息，请参阅ASP.NET Core Blazor WebAssembly 本机依赖项。

Blazor WebAssembly 支持提前 (AOT) 编译，您可以在其中将 .NET 代码直接编译到 WebAssembly 中。AOT 编译以更大的应用程序大小为代价提高了运行时性能。重新链接 .NET WebAssembly 运行时会修剪未使用的运行时代码，从而提高下载速度。有关详细信息，请参阅提前 (AOT) 编译和运行时重新链接。

Blazor 支持在预呈现页面中保留状态，以便在应用程序完全加载时不需要重新创建状态。有关详细信息，请参阅预渲染和集成 ASP.NET Core Razor 组件。

错误边界提供了一种在 UI 级别处理异常的便捷方法。有关详细信息，请参阅处理 ASP.NET Core Blazor 应用程序中的错误。

的元件元件被支撑到SVG内显示任意HTML。有关详细信息，请参阅ASP.NET Core Razor 组件。

Blazor 支持优化的字节数组 JS 互操作，可避免将字节数组编码和解码为 Base64。有关详细信息，请参阅以下资源：

• 从 ASP.NET Core Blazor 中的 .NET 方法调用 JavaScript 函数
• 从 ASP.NET Core Blazor 中的 JavaScript 函数调用 .NET 方法

改进了对使用查询字符串的支持。有关详细信息，请参阅ASP.NET Core Blazor 路由和导航。

绑定支持元素的多个选项选择。有关详细信息，请参阅以下资源：

• ASP.NET Core Blazor 数据绑定
• ASP.NET Core Blazor 表单和验证

Razor 组件可以修改页面的 HTML元素内容，包括设置页面的标题（