深度解析 Microsoft MCP 仓库中的.NET Native AOT 架构与工程实践

1. 智能体时代的架构范式转移与 MCP 的崛起

在人工智能技术从单纯的文本生成迈向自主智能体（Agentic AI）的演进过程中，软件架构的基础设施正经历着一场静默却剧烈的变革。大语言模型（LLM）不再仅仅是被动的问答引擎，它们正在演变为能够感知环境、通过工具采取行动并从结果中学习的智能实体。在这种新的计算范式下，模型上下文协议（Model Context Protocol, MCP）应运而生，作为一种标准化的通用接口，它旨在解决AI模型与外部数据、工具及资源之间的连接难题。microsoft/mcp 仓库作为微软在这一领域的参考实现，特别是其核心组件 Azure MCP Server，承载着将庞大的 Azure 云生态系统接入 AI 智能体世界的战略使命。

然而，这种接入方式与传统的云原生微服务存在本质的区别。传统的微服务通常部署在 Kubernetes 集群中，长期运行，能够容忍几秒钟的冷启动时间，并依靠即时编译器（JIT）在运行过程中逐步优化代码路径。相比之下，MCP 服务器往往作为一种“边车”（Sidecar）进程，或者是由开发者工具（如 Visual Studio Code、Cursor）按需启动的本地命令行工具（CLI） 。在开发者的本地机器上，或者在资源受限的临时容器中，每一毫秒的延迟都会直接破坏用户的交互体验。当一个 AI 智能体试图列出用户的数据库资源时，如果底层的 MCP 工具需要数百毫秒甚至数秒来加载运行时并预热，这种“卡顿”对于流畅的自然语言交互是致命的。

正是在这种极端的性能与资源约束下，.NET Native AOT（Ahead-of-Time，提前编译）技术成为了 microsoft/mcp 项目的核心架构支柱。Native AOT 不仅仅是一个构建选项，它代表了一种全新的工程哲学：通过在编译时进行封闭世界的全量分析，剥离所有不必要的元数据与代码，将庞大的托管运行时应用程序压缩为单一的、无依赖的本机机器码文件。这使得 Azure MCP Server 能够在毫秒级启动，并以极低的内存占用运行，从而满足 MCP 协议对高响应速度和低资源消耗的严苛要求 。

本文将对 microsoft/mcp 仓库进行详尽的解剖分析，深入解构其如何利用.NET Native AOT 技术克服云 SDK 中常见的反射依赖、动态加载和复杂的身份验证挑战。我们将结合仓库中的构建脚本（如 Analyze-AOT-Compact.ps1）、项目结构约定（如 BuildNative 属性）以及新兴的“Compact”库生态系统（如 Microsoft.Azure.Cosmos.Aot），全面揭示微软如何通过工程创新，保障 MCP 服务在 Native AOT 环境下的兼容性与发布稳定性 。

2. 技术背景与架构动因：为何 MCP 必须拥抱 Native AOT

要理解 microsoft/mcp 中的工程决策，首先必须深入剖析 MCP 协议的运行机制与.NET 运行时的性能特征之间的张力。这不仅仅是关于代码的优化，更是关于运行时环境与应用场景的深度匹配。

2.1 MCP 协议的生命周期与性能约束

模型上下文协议（MCP）定义了一种客户端-主机-服务器（Client-Host-Server）的架构模式。在这种模式下，AI 应用程序（作为客户端）通过主机进程与提供特定功能的服务器进行通信。这种通信通常基于标准输入/输出（stdio）流或轻量级的 HTTP/SSE 传输 。这意味着 MCP 服务器往往不是作为守护进程长期驻留，而是随着会话的建立和销毁而频繁地启动和停止。

考虑一个典型的开发者场景：用户在 IDE 中打开了一个包含 Azure 项目的工作区。IDE 可能会立即尝试启动 Azure MCP Server 以获取当前的云资源上下文。此时，MCP 服务器表现为一个本地的可执行文件。如果该文件是基于传统的.NET CoreCLR 运行，其启动过程涉及以下繁重的步骤：

1. 加载运行时：操作系统必须加载 CoreCLR 动态链接库。

2. JIT 编译：运行时需要解析中间语言（IL），验证元数据，并将热点代码路径即时编译为本机机器码。

3. 依赖加载：庞大的 Azure SDK 依赖树（涉及 HTTP 客户端、序列化器、认证库等）需要被加载到内存中。

根据相关性能基准测试，传统的 JIT 模式启动时间通常在 200 毫秒以上，且内存占用较高。而在 Native AOT 模式下，由于代码已被预先编译为本机机器码且经过了激进的裁剪（Trimming），启动时间可缩短至 12 毫秒左右，内存占用减少近 80% 。对于旨在作为轻量级工具链一环的 MCP 服务器而言，这种性能提升不仅是锦上添花，更是其可用性的基石。

2.2.NET Native AOT 的深层机制与限制

Native AOT 代表了.NET 平台向系统级编程领域的一次重要回归。与传统的单文件发布（Single File Publish）不同，后者仅仅是将 IL 程序集和运行时打包在一起，解压后依然依赖 JIT 执行；而 Native AOT 是真正的将 IL 转换为机器码，并链接了一个极简的运行时（主要负责垃圾回收和异常处理），完全摒弃了 JIT 编译器。

然而，这种性能的飞跃伴随着严格的约束，即“封闭世界假设”（Closed World Assumption）。为了生成优化的机器码，编译器必须在构建时知道所有可能被执行的代码。这就直接导致了两个核心限制，这两个限制深刻影响了 microsoft/mcp 的架构设计：

1. 反射（Reflection）的受限：虽然 AOT 支持部分反射，但对于那些依赖运行时动态扫描类型、方法或属性的代码（例如传统的 Newtonsoft.Json 序列化或依赖注入容器），AOT 编译器（IL Linker/Trimmer）无法静态分析出哪些代码是被使用的，从而可能错误地将其裁剪掉，导致运行时崩溃（MissingMethodException）。

2. 动态代码生成的禁止：AOT 环境下无法在运行时生成新的可执行代码。这意味着依赖 System.Reflection.Emit 的库（如某些旧版的 ORM 框架或 Mock 库）将完全无法工作。

microsoft/mcp 仓库中的所有工程实践，本质上都是为了在享受 AOT 带来的性能红利的同时，规避或解决上述两个核心限制。

3. 仓库解构：为 AOT 而生的项目拓扑

通过对 microsoft/mcp 仓库结构的深度审视，我们可以清晰地看到微软工程团队是如何通过物理隔离和特定的命名约定来管理 AOT 兼容性的。这不仅仅是一个代码仓库，更是一个针对 AOT 编译优化的生产流水线。

3.1 目录结构的战略布局

仓库的根目录布局清晰地划分了核心服务逻辑与工程支持设施：

● servers/Azure.Mcp.Server/：这是核心战场。该目录包含了 Azure MCP 服务器的具体实现代码。深入该目录，我们会发现 Program.cs 和项目文件 .csproj 被精心配置以支持双重编译模式——既支持传统的调试模式，也支持严格的 Native AOT 发布模式 。

● eng/scripts/：这是一个至关重要的工程目录，包含了用于构建验证和发布的 PowerShell 脚本。其中，Analyze-AOT-Compact.ps1 和 AOT-Config.ps1 的存在极具揭示性。这些脚本不仅仅是构建工具，它们是质量控制的守门员，负责在持续集成（CI）过程中强制执行 AOT 的兼容性检查，防止任何破坏“裁剪友好性”（Trimming Friendliness）的代码被合并到主分支。

3.2 “Compact” 架构理念的浮现

我们发现了如 Microsoft.Azure.Cosmos.Aot 和 Microsoft.Azure.Mcp.AzTypes.Internal.Compact 这样的专用 “Compact”（紧凑/精简）NuGet 包 。这揭示了一个深层次的架构策略：为了适应 MCP 和 AOT 的需求，微软正在构建一套并行的、轻量级的 Azure SDK 生态系统。

标准的 Azure SDK（通常以 Azure.* 或 Microsoft.Azure.* 命名）为了保证最大的兼容性和开发者体验，往往包含了大量的辅助功能、复杂的重试逻辑、以及基于反射的序列化机制。这些特性虽然强大，但对于 AOT 编译器来说却是沉重的负担，因为它们引入了大量的代码路径，导致最终的可执行文件体积膨胀，且容易触发裁剪警告。

“Compact” 系列库的出现，标志着一种针对特定场景的优化分支：

● 去除动态特性：这些库很可能移除了所有依赖运行时动态行为的代码，转而使用源代码生成器（Source Generators）在编译时生成序列化逻辑和客户端智能体。

● 类型系统的简化：AzTypes.Internal.Compact 暗示了内部数据传输对象（DTO）的重新设计。为了适应 MCP 协议的数据交换格式，这些类型可能被设计为更扁平、更利于静态分析的结构，避免了复杂的继承关系。

● 针对性裁剪：这些库在设计之初就考虑了裁剪属性（`` 等），主动告知编译器哪些代码必须保留，哪些可以安全丢弃，从而在不牺牲稳定性的前提下实现极致的体积缩减。

3.3 构建配置与 Feature Flags

在 servers/Azure.Mcp.Server/src/Azure.Mcp.Server.csproj 项目文件中，我们可以推断出存在复杂的条件编译逻辑。根据相关的问题追踪记录，一个名为 BuildNative 的 MSBuild 属性起到了核心开关的作用。

<PropertyGroup Condition="'$(BuildNative)' == 'true'">
<PublishAot>true</PublishAot>
<PublishTrimmed>true</PublishTrimmed>
<PublishSingleFile>true</PublishSingleFile>
<EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
</PropertyGroup>

当开发者或 CI 流水线执行 dotnet publish -p:BuildNative=true 时，整个构建上下文发生切换。系统不仅激活了 AOT 编译器，更重要的是，它可能通过条件引用（Conditional ItemGroup）将项目依赖从标准的 Azure SDK 切换到了上述的“Compact”版本。这种机制确保了开发人员在调试时可以使用功能完整的标准库以获得更好的调试体验，而在发布时则无缝切换到高度优化的 AOT 栈。

4. 攻克技术壁垒：配置、认证与序列化的 AOT 改造

在将一个庞大的云服务管理工具迁移到 Native AOT 平台时，真正的挑战在于细节。microsoft/mcp 仓库的维护者们必须逐一解决.NET 生态系统中三大传统的“动态”支柱：配置系统、身份验证和数据序列化。

4.1 配置绑定的静态化革命

在传统的 ASP.NET Core 应用中，读取 appsettings.json 并将其绑定到 C# 强类型对象（Options Pattern）几乎完全依赖反射。ConfigurationBinder.Bind() 方法会遍历目标类的所有属性，匹配配置键值。这种做法在 AOT 环境下是致命的，因为裁剪器（Trimmer）无法预知配置文件中会写什么，因此可能会错误地裁剪掉配置类的设值方法（Setters），导致运行时配置失效，且通常不会抛出明显异常，只是静默失败。

为了解决这一问题，Azure MCP Server 激进地采用了 Configuration Binding Generator（配置绑定源代码生成器）。相关的 GitHub Issue 讨论了在启用 <EnableConfigurationBindingGenerator/> 时遇到的警告问题。这个生成器的工作原理是拦截对 Bind() 或 GetValue<T>() 的调用，并在编译时分析目标类型，生成硬编码的绑定逻辑（即显式的 options.Property = config["Key"] 代码）。

这一转变消除了运行时的反射开销，并确保所有被绑定的属性都被编译器静态引用，从而免于被裁剪。然而，这也带来了新的挑战，例如与 dotnet format 工具的兼容性问题，以及对某些复杂嵌套配置结构的支持限制。microsoft/mcp 团队在这一领域的探索，实际上是在为整个.NET 社区在 AOT 配置管理方面踩坑和铺路。

4.2 身份验证的 AOT 困境与突围

身份验证是云服务交互的基石，也是 AOT 迁移中最棘手的环节。Azure Identity 库（Azure.Identity）及其底层依赖 Microsoft.Identity.Client (MSAL) 历史上充满了动态行为。它们需要动态加载平台特定的组件（如 Windows 上的 Web Account Manager 或 macOS 上的 Keychain 访问器），并处理复杂的 OAuth2 令牌序列化。

¹⁶ 和 ¹⁷ 的研究片段揭示了在编译 Azure MCP Server 时，开发者遇到了 Microsoft.Identity.Client.NativeInterop 相关的 IL3000 和 IL2026 错误。特别是 ConfigurationBinder.Bind 在 AddMicrosoftIdentityWebApi 扩展方法中的使用，直接触犯了 AOT 的禁忌。

为了突围，Azure MCP Server 采取了多管齐下的策略：

1. 原生互操作层的重构：引入 Microsoft.Identity.Client.NativeInterop 库，这表明团队正在将底层的原生调用逻辑从托管的反射调用迁移到更静态的 P/Invoke 定义，以适应 AOT 编译器的静态分析需求。

2. 条件编译屏蔽动态流：在 MCP 的服务器场景下，交互式的浏览器登录（Interactive Browser Credential）可能并不适用或难以在无头（Headless）环境中实现。因此，代码中很可能使用了 #if BUILD_NATIVE 预编译指令，在 AOT 构建中彻底剔除那些依赖复杂 UI 交互或动态加载浏览器的认证流，仅保留支持 Managed Identity（托管标识）、Environment Variable（环境变量）或 Workload Identity（工作负载标识）等更适合服务器端且易于静态化的认证方式。

4.3 序列化的零反射之路

MCP 协议本质上是基于 JSON-RPC 的。所有的请求、响应、资源列表和工具调用都通过 JSON 进行传输。在 AOT 之前的时代，Newtonsoft.Json 是绝对的霸主，但其基于反射的机制使它成为 AOT 的天敌。

microsoft/mcp 仓库无可置疑地全面采用了 System.Text.Json，并配合 Source Generator 模式（JsonSerializerContext）。这种模式要求开发者为每一个需要序列化的类型显式定义上下文：

internal partial class McpJsonContext : JsonSerializerContext
{
}

通过这种方式，JSON 序列化逻辑在编译时就被生成为静态的 C# 代码，完全避免了运行时的类型扫描。这不仅解决了兼容性问题，还带来了巨大的性能提升。考虑到 MCP 服务器需要高频处理大量的 JSON 消息，这种优化对于降低延迟至关重要。

5. 构建流水线与发布工程：从源码到二进制的炼金术

了解了代码层面的改造后，我们需要审视 microsoft/mcp 如何通过其工程系统将这些代码转化为最终的发布产物。这里的关键在于构建脚本的自动化验证与跨平台编译的复杂性。

5.1 深入解析 Analyze-AOT-Compact.ps1

Analyze-AOT-Compact.ps1主要功能是自动化检测 .NET 项目的 Native AOT（Ahead-of-Time 编译）兼容性。它通过执行 dotnet publish 并开启裁剪（Trimming）分析，捕获特定的 IL（中间语言）警告，尝试将这些警告归以此类到具体的 DLL 程序集中，最后生成 JSON 和 HTML 格式的报告。这个脚本是 CI/CD 流程中的“质量门禁”（Quality Gate）。

这个脚本是一个专业的工程化工具，用于 .NET AOT 迁移或维护阶段。它的核心价值在于：

l 降噪与分类：原始的 dotnet publish 输出可能包含成百上千行日志，混杂在一起。此脚本将警告按 DLL 分组，让开发者一眼看出是哪个第三方库（如 Newtonsoft.Json 或 AutoMapper）在阻碍 AOT 编译。

l 自动化门禁：通过返回值控制，可以轻松集成到 GitHub Actions 或 Azure DevOps 中，作为 PR 合并前的质量门禁（Quality Gate）。

l 启发式归因：利用命名空间与程序集名称的强相关性，解决了日志中只报类名不报 DLL 来源的痛点。

建议改进点： 如果项目引用了大量 NuGet 包，bin 目录下的 DLL 扫描可能不够全面（如果是 NuGet 缓存引用）。但在 self-contained 发布模式下，所有依赖都会被拷贝，所以当前的逻辑是自洽且稳健的。

5.2 macOS 链接器崩溃之谜与边缘计算挑战

在构建流水线中，最引人注目的问题莫过于在 macOS 上为.NET 10 编译 MCP Server 时遇到的 ld64 链接器崩溃 。错误信息 Assertion failed: (_addend == uniqueIndex && "too many large addends") 揭示了一个深层次的系统级问题。

这表明 Azure MCP Server 即使在经过裁剪后，其包含的符号数量（Symbols）或重定位条目（Relocations）依然庞大到了触及 macOS 原生链接器处理能力的边界。通常，这种问题只会出现在超大规模的 C++ 项目中。这一现象从侧面印证了 Azure SDK 的复杂性，以及将其完全静态链接到一个单一可执行文件中的工程难度。

为了解决这个问题，微软团队不得不深入到底层的对象文件（Object File）生成逻辑，调整.NET 编译器（ILC）生成 Mach-O 文件的方式，或者等待 Apple 工具链的更新。这也提醒了所有试图在 macOS 上开发大型 Native AOT 应用的开发者：你正行走在技术的最前沿，可能会踩到操作系统工具链本身的 Bug。

5.3 Docker 与无干扰发布（Distroless）

对于容器化部署，Native AOT 开启了使用极简基础镜像的大门。虽然 Snippet 展示了基于 Alpine 的 Dockerfile，但在 MCP 的上下文中，更先进的实践是使用 Ubuntu Chiseled 镜像。

由于 AOT 编译后的程序不依赖.NET 运行时，Docker 镜像可以不再包含庞大的 dotnet-runtime 层。这种镜像剥离了 Shell、包管理器（apt）以及所有非必要的系统库，仅保留 glibc 和 openssl 等最基础的本机依赖。

这种做法为 MCP 服务带来了双重优势：

1. 安全性：由于没有 Shell，攻击者即使利用漏洞进入容器也难以执行命令，攻击面被极度压缩。

2. 体积：最终的镜像大小可能仅为 30-50MB，这使得 MCP 服务可以在 Kubernetes 集群中实现秒级扩容，完美契合 AI 智能体按需调用的特性。

6. 生态系统的二元分化与“Compact”战略的未来

microsoft/mcp 仓库所展现的工程实践，实际上预示了.NET 云开发生态系统的一个重大分水岭。我们正在目睹 SDK 生态的二元分化：

特性维度	标准 Azure SDK (Standard)	Compact / AOT Azure SDK
目标场景	传统的 Web 应用、企业级微服务	CLI 工具、Sidecar、FaaS (Serverless)、MCP Server
运行时要求	完整的 CoreCLR，支持 JIT	Native AOT，无依赖，自包含
灵活性	高（依赖注入、动态加载插件）	低（静态链接、编译时确定）
配置方式	运行时反射绑定 (Bind)	编译时源代码生成 (Source Gen)
序列化	兼容性优先 (Newtonsoft)	性能优先 (System.Text.Json + Context)
启动速度	200ms+	< 20ms

Microsoft.Azure.Cosmos.Aot 的出现并不是一个孤立事件，它是这一战略的具体体现。对于 Cosmos DB 这样复杂的客户端，标准版为了支持 SQL 查询的动态 LINQ 转换，大量使用了 Expression Tree 编译，这在 AOT 下是受限的。AOT 版本通过限制查询构建的动态性，或者预先生成查询计划，换取了极致的启动速度和内存效率。

这一战略对于 MCP 的未来至关重要。随着 AI 智能体需要集成的工具越来越多（从数据库到消息队列，再到认知服务），如果每个工具的 SDK 都像以前那样臃肿，MCP Server 将变得极其庞大且迟缓。通过“Compact”化，微软实际上是在为 AI 时代重写其云基础设施的客户端层。

7. 实践指南：开发 AOT 兼容的 MCP 服务

基于对 microsoft/mcp 仓库的分析，对于希望开发高性能、AOT 兼容的 MCP 服务的开发者，以下是具体的实践建议：

7.1 环境与项目配置

首先，确保你的开发环境安装了最新的.NET 10 SDK，以及对应平台的 C++ 编译工具链（Windows 上的 MSVC 或 macOS 上的 Xcode Command Line Tools）。

在你的 .csproj 文件中，必须显式启用 AOT 相关的属性，并引入源代码生成器支持：

<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<PublishAot>true</PublishAot>
<EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
<TrimMode>full</TrimMode>
<IlcDisableReflection>true</IlcDisableReflection>
</PropertyGroup>

7.2 依赖管理与代码规范

● 慎选依赖：在引入第三方 NuGet 包之前，务必检查其是否标记为 AOT 兼容。避免使用依赖旧版 System.Reflection 的库。如果必须使用 Azure 服务，优先寻找带有 .Aot 或 .Compact 后缀的预览版包。

● 摒弃动态 JSON：绝对不要使用 dynamic 关键字处理 JSON。定义严格的 DTO 类，并使用 System.Text.Json 的源生成器模式。

● 依赖注入的静态化：虽然 Microsoft.Extensions.DependencyInjection 支持 AOT，但要避免使用 Scan 等扫描程序集注册服务的方式。应显式地注册每一个服务：services.AddSingleton<IMyService, MyService>()，以便链接器能够追踪引用关系。

7.3 构建与调试策略

● 本地模拟发布：不要只依赖 dotnet run（它是 JIT 模式）。经常运行 dotnet publish -p:PublishAot=true 来验证构建是否成功。

● 关注警告：将 IL2026 和 IL3050 警告视为错误。每一个警告都可能代表运行时的一个潜在崩溃点。使用 `` 属性标记那些确实需要动态行为的方法，并将这种“污染”隔离在代码库的一小部分中。

● 利用 Docker 进行验证：在最终发布前，构建一个基于 Chiseled 镜像的 Docker 容器并在其中运行测试。这能捕捉到因缺少原生依赖（如 ICU 库或 OpenSSL）而导致的运行时问题。

8. 结语

microsoft/mcp 仓库不仅是 AI 智能体与 Azure 云之间的桥梁，它更是一部关于.NET 现代化工程的教科书。通过深入剖析其对 Native AOT 的全面拥抱，我们看到了一场针对“速度”与“体积”的极致追求。

从底层的构建脚本 Analyze-AOT-Compact.ps1 对警告的严防死守，到上层架构中“Compact” SDK 生态的战略布局，再到对配置和认证模块的源代码生成改造，每一个细节都服务于同一个目标：让 AI 智能体的工具调用像神经反射一样迅速。

对于广大开发者而言，microsoft/mcp 的启示在于：在 AI 原生时代，软件的性能指标已经从吞吐量（Throughput）转向了延迟（Latency）和冷启动能力。拥抱 Native AOT，不仅是技术栈的选择，更是适应这一新时代的必然进化路径。虽然目前的工具链（如 macOS 链接器问题）仍有待完善，但方向已经确立——未来的云工具，必将是编译的、紧凑的、且即时响应的。

引用的链接：

1. Get started with the Azure MCP Server - Microsoft Learn, 访问时间为 十二月 4, 2025， https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/get-started

2. A Deep Dive into Jihad Khawaja's .NET Filesystem MCP Server: Your AI's Bridge to Local Files - Skywork.ai, 访问时间为 十二月 4, 2025， https://skywork.ai/skypage/en/A-Deep-Dive-into-Jihad-Khawaja's-.NET-Filesystem-MCP-Server-Your-AI's-Bridge-to-Local-Files/1977932030437429248

3. Uncategorized Archives - Azure Greg, 访问时间为 十二月 4, 2025， https://gregorsuttie.com/category/uncategorized/

4. azure-developer-cli - Tag | Azure SDK Blog, 访问时间为 十二月 4, 2025， https://devblogs.microsoft.com/azure-sdk/tag/azure-developer-cli/feed/

5. chasecuppdev/contextkeeper-mcp - GitHub, 访问时间为 十二月 4, 2025， https://github.com/chasecuppdev/contextkeeper-mcp

6. `dotnet format` raises native AOT warnings regardless of `

7. Azure SDK for .NET (All), 访问时间为 十二月 4, 2025， https://azure.github.io/azure-sdk/releases/latest/all/dotnet.html

8. ld64 crashing while Native AOT compiling Microsoft MCP for .NET 10 #119380 - GitHub, 访问时间为十二月 4, 2025， https://github.com/dotnet/runtime/issues/119380

9. Azure MCP Server | Glama, 访问时间为 十二月 4, 2025， https://glama.fly.dev/mcp/servers/@Azure/azure-mcp/blob/b8fb975d73fb120aceeb1ea271c64751fd3f11b2/eng/scripts/Update-Version.ps1

10. Architecture overview - Model Context Protocol, 访问时间为十二月 4, 2025， https://modelcontextprotocol.io/docs/learn/architecture

11. 访问时间为 一月 1, 1970， https://github.com/microsoft/mcp/blob/main/servers/Azure.Mcp.Server/src/Azure.Mcp.Server.csproj

12. 访问时间为 一月 1, 1970， https://github.com/microsoft/mcp/blob/main/servers/Azure.Mcp.Server/src/Program.cs

13. Azure MCP Server | Glama, 访问时间为 十二月 4, 2025， https://glama.fly.dev/mcp/servers/@Azure/azure-mcp/blob/b8fb975d73fb120aceeb1ea271c64751fd3f11b2/eng/scripts/Deploy-TestResources.ps1

14. 访问时间为 十二月 4, 2025， https://raw.githubusercontent.com/Azure/azure-sdk/main/_data/releases/latest/dotnet-packages.csv

15. renliguo/AspNetCore - Gitee, 访问时间为 十二月 4, 2025， https://gitee.com/renliguo/AspNetCore/blob/master/Directory.Build.props

16. Trim and AOT-incompatible APIs · Issue #3576 · AzureAD/microsoft-identity-web - GitHub, 访问时间为 十二月 4, 2025， https://github.com/AzureAD/microsoft-identity-web/issues/3576

17. [Bug] Microsoft.Identity.Client.NativeInterop Incompatibility with Native AOT compilation · Issue #5226 · AzureAD/microsoft-authentication-library-for-dotnet - GitHub, 访问时间为十二月 4, 2025， https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/5226

18. wexflow/src/docker/Dockerfile at main - GitHub, 访问时间为十二月 4, 2025， https://github.com/aelassas/Wexflow/blob/master/src/docker/Dockerfile

19. Database APIs - nuget - Socket - Socket.dev, 访问时间为十二月 4, 2025， https://socket.dev/nuget/category/apis/database-apis?page=4