Cascadia Code 2404.23

Hello world! We are excited to announce the first major version update of Cascadia Code since the 2111.01 release three years ago! (Wow, time sure flies!) In this new 2404.03 release, we have added support for Quadrants, Sextants, Octants, Large Type Pieces,

MSTest SDK:.NET 8的测试配置与灵活性新篇

本篇翻译于Marco Rossignoli 和Amaury Levé 的Introducing MSTest SDK – Improved Configuration & Flexibility。 我们很高兴地宣布,基于 MSBuild Project SDK 系统构建的全新 MSTest SDK已推出。它旨在通过合理的默认值和灵活的选项使项目配置更加容易,从而为您提供更好的 MSTest 测试体验。  这种新体验是建立在最近推出的 MSTest 运行程序的基础上(请查看公告)https://devblogs.microsoft.com/dotnet/introducing-ms-test-runner/,以进一步提高您的体验。 这个新的运行程序是一种轻量级、可靠且高性能的运行 MSTest 测试的方式,作为 MSTest.TestAdapter NuGet 包的依赖项发布。该运行器及其扩展由多个 NuGet 包组成,以提供可扩展、灵活且可配置的测试运行体验。然而,可定制性可能会导致许多问题:推荐的扩展是什么?正确的默认值是什么?如何对齐版本? 这就是 MSTest SDK 的用武之地。  MSTest SDK 入门  开始使用新的 MSTest SDK 非常简单。 只需创建一个 MSTest 项目(或更新现有的 MSTest 项目)并将 .csproj 文件的内容替换为以下内容: <Project Sdk="MSTest.Sdk/3.3.1">

使用 .NET 为 Microsoft AI 构建可扩展网关 

本篇翻译于Kara Saucerman的Building a scalable gateway with .NET for Microsoft AI – .NET Blog  Microsoft AI 团队构建了全面的内容、服务、平台和技术,以便消费者在任何设备上、任何地方获取他们想要的信息,并为企业改善客户和员工的体验。我们的团队支持多种体验,包括 Bing、Copilot、广告、地图和 Edge,并通过 Edge 新标签页、Windows 10 和 11 等入口点呈现,这些入口点每月有超过 10 亿活跃用户。我们意识到需要一个高性能且可靠的网关作为 Microsoft AI 的前端和入口层。这将使多个团队能够利用我们开发的通用功能来帮助运营业务并专注于客户体验和功能。在本文中,我们将介绍在 .NET 8 上借助 YARP 构建网关(代号为 CETO)的过程。  反向代理  在开始编写 CETO 之前,我们必须决定使用反向代理。 我们应该使用外部的还是尝试自己制作? 这些外部的能涵盖我们所有的用例吗? 我们还必须考虑定制这些代理的高成本和持续维护。 我们的需求包括支持 HTTP/2、HTTP/3、WebSocket 等流协议、简单的可扩展性等等。 当我们开始了解 Microsoft 其他内部团队正在做的事情时,我们遇到了 YARP 项目。 YARP 代表:“又一个反向代理”。 该项目使用 ASP.NET 和 .NET(.NET 6 及更高版本)提供一个灵活的解决方案,可以通过 .NET 代码进行修改。这有多方便呢? 事实证明这正是我们所需要的。  Bing 运行着世界上最大、高性能且可靠的 .NET 应用程序之一。 我们依赖于与 .NET 团队的密切合作关系,并且是每个 .NET 版本的早期采用者。 通过尝试并升级到每个新版本,我们可以向 .NET 团队提供有用的反馈。 这有助于我们的平台和那些将升级服务以使用这些新版本的外部客户。 我们将 YARP 纳入该反馈周期。  在现代 .NET 上创建新服务  由于 CETO 是一项新的服务,我们当时有机会使用最新的.NET版本。 如今,它构建在 .NET 8、Kestrel + YARP 2.1 之上,可以在多个基础设施平台和数千台服务器上运行,既支持Linux容器也支持Windows容器。 跨平台运行的能力增加了我们模块的可移植性和兼容性,以及在任何地方部署的灵活性和效率。 在这个层面上的性能非常快,每一毫秒都至关重要。CPU%较低,从而降低了运营成本。  CETO 通过统一我们平台上的业务逻辑来实现融合,然后将请求交给 YARP,以完成路由到适当上游服务的繁重工作。 我们希望我们的路由和映射能够高度定制化,因为我们要处理许多具有不同流量模式的不同群体,这会影响其他关键功能。  灵活性至关重要  我们对如何使用 .NET 和 YARP 有很多选择和控制权,因为它们非常灵活且功能多样。 .NET提供了各种各样的API,以满足不同的需求,例如配置、依赖注入、日志记录、测试和调试等。 通过使用 .NET,我们的 CETO 开发人员可以编写灵活、易于维护的代码,无缝连接到我们的其他服务。  我们采取了以下几种方法来满足我们的需求:  我们希望从一个中心位置管理我们内部团队的客户流量路由和目的地。 使用 YARP,我们可以通过提供几个实现 IProxyConfigProvider 和 IProxyConfig 接口的类来选择从外部加载配置。 团队可以创建任意数量的简单或复杂的路由,并与其他团队分开部署。 更改会在后台重新加载,然后我们用新的快照交换代理配置状态,通知旧的配置已过时。  由于使用完整的 YARP 代理,我们具有路由和负载平衡的优势。 我们希望提供一个选项,当从服务收到某些 http 状态代码时,转发到另一个位置。 团队可以在 YARP 路由配置的 IReadOnlyDictionary<string,

Filters in Semantic Kernel

It’s important to understand how the application behaves and have the ability to override that behavior in runtime based on some conditions. For example, we don’t want to send malicious prompt to LLM, and we don’t want to expose more information than needed to the end users.