Windows 应用开发常见问题解答

本常见问题解答提供了有关Windows应用程序开发的常见问题的解答，包括有关为项目选择合适的框架的指导。 涵盖的主题包括：

  • 入门指南和 Windows 应用开发环境。
  • 使用 WinUI 3、Windows Presentation Foundation (WPF) 和 Windows 窗体 (WinForms) 进行仅限 Windows 的本机应用程序开发。
  • Windows软件开发工具包（SDK）和Windows 应用 SDK。
  • 将 Windows 作为跨平台开发战略的一部分。
  • 使用 .NET MAUI、Blazor 和 ASP.NET Core 进行混合和 Web 应用开发。
  • 如何在了解微软投资的同时选择一个策略。

Windows应用开发环境

在哪里可以找到Windows开发技术的简单概述？

若想了解当今 Windows 开发者可选择的方案概览，请观看 Windows Dev Chat 节目选择最适合你的开发平台这一期，其中讨论了 WinUI 3、.NET MAUI、React Native、Blazor 和渐进式 Web 应用（PWA）。 可以在Windows开发聊天播放列表中找到其他剧集。

您还可以参考供 Windows 开发人员使用的应用开发选项概述。

为什么在云服务时代的现代数字化转型中，客户端应用开发仍然至关重要？

在云服务时代，客户端应用开发对于在用户设备上提供响应式、有意义的交互仍然很重要。

下面是客户端应用很重要的原因：

  • 设备访问范围： 使用客户端应用，可以将应用程序直接带到所选设备上的用户。
  • 智能服务的门户： 客户端应用通常是用户与服务的第一次交互。 它们提供丰富的交互式界面，使你能够展示智能功能并将产品与其他产品区分开来。
  • 云集成的可扩展性：一个良好集成的客户端应用可以毫不费力地与后端云服务同步，从而在用户群增长时实现实时数据访问和无缝扩展性。
  • 提高工作效率和用户忠诚： 经过深思熟虑的应用可以提高工作效率，并使用户随着时间的推移与产品或服务保持参与。

原生Windows仅限应用开发

什么是 Windows 应用 SDK？

Windows 应用 SDK为Windows桌面应用（包括 WinUI 3、应用生命周期、窗口化、通知、资源和文本 API）提供独立服务组件。 它支持在 Windows 10 版本 1809 及更高版本上运行的应用，具体取决于Windows版本和Windows 应用 SDK版本的支持生命周期。

Windows 应用 SDK与Windows SDK之间的区别是什么？

两者都是软件开发工具包（SDK），可用于生成Windows应用。

Windows 应用 SDK提供独立于 Windows 发布的组件，并可在受支持的各个 Windows 版本上运行，最低支持到 Windows 10 版本 1809。 它包括 WinUI 3 和应用生命周期、窗口化、通知、资源、文本和其他功能的 API。

Windows SDK 为操作系统 API（如 Win32、WinRT、COM、DirectX、设备和 shell 功能）提供标头、库、元数据和工具。

Windows 应用 SDK不会替换Windows SDK。 采用Windows 应用 SDK的应用可以继续使用Windows SDK API，而 WinUI 3 应用通常同时使用这两种 API。

我正在构建一个新团队来开发仅限Windows的应用。为何应选择使用 WinUI 3、WPF 或 WinForms 等本机Windows框架进行开发？

选择本地Windows框架作为仅限于Windows的应用的原因如下：

  • 性能：本机 Windows 框架经过优化，可以利用新式 Windows 硬件，提供快速的响应式的用户体验。
  • Integration： Windows附带各种 API，这些 API 仅支持Windows上提供的复杂体验。 本机框架提供与这些功能和 API 的深度集成。
  • 原生用户体验：原生框架在 Windows 设备上提供一致的体验，确保您的应用无论在何处运行都具有出色的外观和性能。
  • 脱机支持： 本机框架支持脱机方案，即使没有 Internet 连接，应用也能正常运行。
  • 支持和工具：Microsoft维护本机框架，并提供当前的 SDK、文档、调试工具和示例。
我应该使用哪种框架来利用Microsoft在Windows应用开发方面的最新投资？

如果要构建新的常规用途Windows桌面应用，建议使用 WinUI 3。 WinUI 3 是随Windows 应用 SDK一起提供的本机 UI 框架。 它支持Windows桌面应用，并提供对当前 Fluent 控件和Windows平台功能的访问权限。

是否可以在现有Windows应用中使用 Windows 应用 SDK/WinUI 3？

请注意，WinUI 3（UI 框架）附带Windows 应用 SDK（Windows平台开发框架）。

可以将应用的 UI 迁移到 WinUI 3，或使用 WinUI XAML 岛在受支持的现有桌面主机上托管Windows 应用 SDK控件。 旧系统 XAML 岛托管 UWP XAML 控件并使用不同的 API。

Windows 应用 SDK的元素通常可用于桌面应用，具体取决于现有应用的生成方式。 Windows 应用 SDK不支持 UWP 应用。

这意味着WPF/MFC/WinForms 应用可以使用与 WinUI 3 无关的Windows 应用 SDK API。 示例包括应用生命周期、窗口化和应用通知。

有关详细信息，请参阅 使用现有项目中的Windows 应用 SDK。

是否需要使用Visual Studio来生成 WinUI 3 应用？

否。 WinUI 3 XAML 生成使用 MSBuild，但可以从另一个编辑器中的命令行使用 .NET SDK 和当前的 WinUI 3 模板进行生成。 请参阅 命令行快速入门。

Visual Studio 2026 提供最丰富的集成编辑、调试、分析和 XAML 热重载体验。 使用与您的工具要求相匹配的工作流。

我在运行应用时收到“无法加载 DLL'Microsoft.ui.xaml.dll'”错误。如何修复？

此错误通常发生在未打包应用方案中，其中尚未在计算机上安装 Windows 应用 SDK 运行时。 请尝试以下做法：

  • 如果运行的是 packaged 应用（建议的默认），请确保通过 Visual Studio 启动，其中选择了 MsixPackage启动配置文件（而不是纯可执行配置文件）。 MSIX 打包步骤安装所需的运行时组件。
  • 如果运行的是依赖于框架的未打包应用，请安装匹配Windows 应用 SDK运行时。 独立部署包括其Windows 应用 SDK依赖项。
  • 确认项目与部署模型匹配。 对于正常.NET未打包的应用，设置<WindowsPackageType>None</WindowsPackageType>启用Windows 应用 SDK运行时自动初始化。 仅当需要显式控制动态依赖项初始化时，才直接使用引导程序 API。

有关部署要求的详细信息，请参阅使用 Windows 应用程序 SDK 部署应用。

适用于 UWP 的 WinUI 3 和 WinUI 2 有何区别？

WinUI 3 是Microsoft Windows桌面应用的当前本机 UI 框架，并作为Windows 应用 SDK的一部分交付。

WinUI 2 也称为 WinUI for UWP，是 UWP 应用的控件和样式库。 WinUI 2 和 WinUI 3 使用不同的 XAML 命名空间，并且不兼容二进制命名空间。

使用 Windows 应用 SDK 和 WinUI 3 生成应用时，是否正在生成“WinUI 应用”？

是的。 WinUI 3 应用是指 UI 采用 WinUI 3 和 Windows 应用 SDK 的应用这一最清晰的称谓。 WinUI 应用在上下文明确时也很常用。

我是否可以通过逐步替换控件，将使用 WinUI for UWP 控件的 UWP 应用逐步升级到 WinUI 3？

否。 Windows 应用 SDK不能在 UWP 应用中使用，而 UWP 的 WinUI 不能与 WinUI 3 混合。 请参阅从 UWP 迁移到 Windows 应用 SDK。

将 UWP 应用迁移到 WinUI 3 有多困难？

UWP 和 WinUI 3 共享许多 XAML 概念，但迁移不是直接的命名空间更改。 成本主要取决于：

  1. Project 文件和 MSBuild 自定义：迁移工作因高级 MSBuild 使用情况而异。
  2. .NET API 迁移：使用 .NET Native 的 UWP 应用可借助 Native AOT 迁移到当前仍受支持的 .NET 版本。 这种现代化独立于将 UI 迁移到 WinUI 3。
  3. UI 组件库： 库必须具有面向 WinUI 3 的版本。
  4. 窗口和应用程序模型 API：与 CoreWindow、ApplicationView 或 GetForCurrentView 等概念相关的 UWP API，需要使用 Windows 应用 SDK 中的替代项，或采用其他桌面应用方法。
  5. C++ 语言投影： 如果 UWP 应用使用取代的 C++/CX 投影，则将该代码移植到 C++/WinRT。

有关详细信息，请参阅从 UWP 迁移到 Windows 应用 SDK，以及将 UWP 迁移到 Windows 应用 SDK API 映射。

如果我在应用商店中有现有的 UWP 应用，是否可以使用相同的标识符发布新的打包的 WinUI 3 应用？

是的，可以在不更新应用程序标识的情况下发布升级的应用。 旧版本的用户将更新为新版本。 这仅适用于桌面应用。 Xbox、HoloLens和标准Surface中心应用无法迁移到 WinUI 3。

如何打包或分发 WinUI 3 应用？

请参阅 包和部署概述。

在哪里可以找到Windows 应用 SDK迁移指南？

请参阅从 UWP 迁移到 Windows 应用 SDK。

如果想要使用 WinUI 3，是否需要使用 XAML 标记？

否。 可以在代码中创建 UI 控件。 但是，在声明性 XAML 标记中表示 UI 提供了许多好处，包括改进的开发人员体验。

  • 从 UWP 迁移到 WinUI 3：许多 XAML 和 UI 概念都延续了，但命名空间、项目模型和一些 API 有所不同。
  • 从 WPF迁移到 WinUI 3：许多概念都延续了，但控件集和 API 有所不同。
Visual Studio是否具有 WinUI 3 的设计图面或 UI 设计器？

目前不能。 使用 XAML 热重载、实时可视化树、实时属性资源管理器和相关运行时工具在应用运行时检查和更新 XAML。

有关适用于 WinUI 3 的运行时设计工具的完整演练，请参阅 WinUI 3 的 XAML 运行时设计工具。

Windows 应用 SDK是否包括 WinUI 3？

是的。 WinUI 3 作为 Windows 应用 SDK 的一部分提供。

Windows 应用 SDK 是否包括适用于 UWP 的 WinUI？

否。 WinUI for UWP 是 UWP 平台的一部分。

WinUI for UWP 和 WinUI 3 是否基于同一技术构建？

并不全面。 虽然 WinUI 3 从 WinUI for UWP 代码库开始，但它们是不同的技术。 这两个框架都是基于 XAML 的 UI 框架，可跨 .NET 和 C++ 工作，但适用于 UWP 和 WinUI 3 的 WinUI 彼此不兼容。

是否可以在不使用 Windows 应用 SDK的情况下使用 WinUI 3？

否。 WinUI 3 作为 Windows 应用 SDK 的一部分提供。

是否可以在未打包的应用中使用 WinUI 3？

是的。 WinUI 3 和许多Windows 应用 SDK API 适用于未打包的应用。 但是，某些Windows功能需要包标识，依赖框架的未打包应用必须初始化Windows 应用 SDK运行时。 比较 打包概述 和 需要包标识的功能中的选项。

XAML 岛和 WinUI 3 之间的区别是什么？

WinUI 3 是Windows 应用 SDK中包含的 UI 框架。 XAML 岛是一种托管技术，它允许现有桌面应用将 XAML 内容与另一个框架中的 UI 一起放置。

该术语可以指托管 UWP XAML 控件的旧系统 XAML 岛，或托管受支持桌面主机中Windows 应用 SDK控件的 WinUI XAML 岛。 API、命名空间和主机要求有所不同。

如果我创建一个 WinUI 3 应用，它在 Windows 11 和 Windows 10 上看起来都会很现代吗？

WinUI 3 控件在受支持的 Windows 10 和 Windows 11 版本上，无论是在打包应用还是未打包应用中，均采用 Fluent 样式。 某些操作系统效果和行为因Windows版本而异。 例如，Mica 在 Windows 11 上可用，而在 Windows 10 上则回退为纯色。

我可以在使用 Windows 应用 SDK 生成的应用中使用 Mica 或 Acrylic 背景吗？

是的。 Windows 10版本 1809 及更高版本支持桌面亚克力。 Mica 需要 Windows 11，在 Windows 10 上则会回退为纯色主题颜色。 在应用背景效果之前，请在运行时调用 MicaController.IsSupported 或 DesktopAcrylicController.IsSupported。 请参阅 在 Windows 11 桌面应用中应用 Mica 或 Acrylic 材料。

在哪里可以找到 WinUI 3 示例？

请参阅示例和资源。 一些值得注意的存储库：

如果我已在WPF投入了大量资金，我是否应继续使用WPF或考虑迁移到 WinUI 3？

如果你已经投入了大量资金用于WPF，则可以继续将其用于现有应用。 WPF是一个成熟的稳定框架，通常用于生成Windows桌面应用。

使用 GitHub Copilot 升级功能评估并将 .NET Framework WPF 应用升级到现代 .NET。 查看生成的计划并验证应用中的每个更改。

如果我构建一个新的WPF应用，它会不会显得比其他新的Windows应用程序过时？

使用 .NET 9 或更高版本开发 WPF 应用程序时，可以确保你的应用与Windows 11的时尚现代外观相匹配。 WPF的新 Fluent 主题引入了当代Windows 11美学，集成了浅色/深色模式和系统主题色支持。 这可使应用的外观现代化，并提供美观、凝聚力良好的用户体验。

我的团队可以舒适地构建 WinForms 应用，它符合我们的需求。是否应考虑迁移到 WinUI 3 或其他框架？

如果 WinForms 满足你的需求，并且团队对它感到满意，则可以继续使用 WinForms 进行现有应用。 WinForms 是一个成熟的稳定框架，通常用于Windows桌面开发。

WinForms 团队继续投资该平台。 最近和正在进行的工作包括：

  • 异步表单和对话框 API
  • 深色模式和视觉样式支持
  • 辅助功能、高 DPI、布局和设计器改进
  • 剪贴板和 DataObject 现代化

跨平台原生开发

构建面向 Windows 的跨平台本地应用有何原因？

如果你面向多个 OS 平台的用户，请使用 .NET MAUI 或 React Native 构建跨平台应用可提供以下几个优势：

  • 市场宣传：跨平台应用可跨不同设备和操作系统触达更多的受众。
  • 代码重用： 跨平台重用代码可缩短开发时间和成本。 为 Windows、Android、iOS 和 macOS 构建单独的应用可能极其昂贵。
  • 一致的用户体验： 跨平台框架有助于跨平台提供一致的外观。
  • 集成： 跨平台应用仍可与特定于平台的服务集成，以提供全面的体验。
.NET MAUI 应用能否在 Windows 上良好地运行？

为Windows生成.NET MAUI应用时，输出使用 WinUI 3。 在开发过程中，.NET MAUI跨平台提供单个.NET体验，但它在后台生成特定于平台的代码。

.NET MAUI如何跨每个平台提供本机设备 API？

.NET MAUI提供跨 Windows、iOS、Android 和 macOS 的统一.NET体验。 它为存储、网络和设备传感器等常见功能提供跨平台 API。 还可以调用特定于平台的 API 或为每个平台提供专用实现。

如果我最终想要面向跨平台场景，是否可以先从 WinUI 3 开始，之后再集成 .NET MAUI？

目前不是。 尽管.NET MAUI在Windows上运行时使用 WinUI 3，但希望面向多个平台的团队应从 .NET MAUI 或 React Native for Desktop 开始。

我们的团队具有强大的 Web 前端开发技能。是否应考虑使用 React Native for Desktop？

具有强大 Web 开发体验的团队可能需要考虑 React Native for Desktop。 它包括 React Native for Windows 和 macOS。 借助“学习一次，随处编写”方法，现有 JavaScript、TypeScript 和 React 技能可用于开发原生 Windows 和 macOS 应用。

适用于桌面的 React Native 将 UI 直接呈现到本机基元，提供本机性能和平台功能。

请参阅 React Native for Desktop 文档以开始使用。

React Native for Desktop 支持其他任何 Windows 设备吗？

React Native for Windows支持其兼容性文档中列出的Windows版本。 请确认你要针对的 React Native for Windows 版本所支持的设备系列，而不要想当然地认为所有 Windows 设备都受支持。

如果我想开发适用于 Windows 和 Xbox 的应用程序，我应该使用什么？

对于Xbox应用，请使用 UWP 并考虑特定于Xbox的 UWP 限制。 对于游戏开发，请使用 Microsoft 游戏开发工具包。

如果我想要构建可以在 Windows 和 Surface Hub 上运行的应用，我应该使用什么？

对于运行标准 Teams Rooms 或 Surface Hub 环境的 Surface Hub，请使用符合 Surface Hub 应用要求 的 UWP 应用。 配置了 Windows 11 Pro 或 Enterprise 的 Surface 中心 3 可以运行受支持的桌面应用技术，因此 UWP 并不是该配置中唯一的选项。

混合和 Web 开发

什么是混合应用，为什么应考虑生成混合应用？

混合应用混合了 Web 和本机应用开发的最佳方案。 其核心是使用 HTML、CSS 和 JavaScript 等 Web 技术构建的，并封装在本机容器中，该容器允许访问某些本机平台功能和硬件。 还可以通过应用商店分发它们。

主要优势是，混合应用允许你构建可在多个本机平台和 Web 上运行的单个应用，从而减少开发时间和成本。 混合应用开发平台的示例包括：

  • 适用于桌面应用的 Electron
  • 适用于移动应用的 Ionic
  • 适用于跨平台应用的 .NET MAUI Blazor 混合
如何在 Windows 上构建具备本机体验的渐进式 Web 应用 (PWA)？

请参阅 Windows 上的 Web 开发 和 渐进式 Web 应用 的概述。

什么是.NET MAUI Blazor 混合应用？

使用 .NET MAUI，Blazor 应用可以在 Windows、iOS、Android 和 macOS 上本机运行。 这样，就可以创建混合客户端应用，将 Blazor 和.NET MAUI组件合并到单个本机客户端应用中，并完全访问本机平台功能。

了解更多信息，请访问 ASP.NET Core Blazor Hybrid。

.NET MAUI 混合应用程序的 Web 组件需要用 Blazor 创建吗？

否。 从 .NET 9 开始，.NET MAUI包括一个 HybridWebView 控件，该控件允许在本机应用中托管其他基于 JavaScript 的 UI。

这样，便可以在.NET MAUI应用中托管 Angular、React、Vue 或其他 HTML/JavaScript 应用。 混合控件在 C# 和 JavaScript 之间提供互作，因此 C# 代码可以调用 JavaScript 函数，反之亦然。

任何其他本机应用类型是否可以托管 Blazor 混合组件？

是的。 WPF和 WinForms 应用还可以托管 Blazor 混合组件，从而将新式 Web UI 添加到现有应用。 WPF或基于 .NET Framework 构建的 WinForms 应用不支持此功能。

我的整个应用是否需要混合应用，或者是否可以混合和匹配本机组件和混合组件？

本机组件和混合组件可以在应用中混合。 例如，可以使用.NET MAUI组件构建应用的核心，而混合组件提供其他功能。 这允许将本机组件的性能和功能与混合组件的灵活性和成本效益相结合。

在 Windows 的现代浏览器中，有哪些构建外观出众的.NET Web 应用的选项？

Web 应用程序拥有任何客户端应用程序平台中最广泛的覆盖范围。 创建美观.NET Web 应用的选项包括：

  • 带有Razor Pages的ASP.NET Core应用程序
  • ASP.NET Core MVC 应用
  • ASP.NET Core Blazor 应用程序，提供多种托管模型选项：
    • Blazor WebAssembly
    • Blazor Server

现在可以在组件级别配置 Blazor 托管模型，从而在 Blazor 服务器应用中托管 Blazor WebAssembly 组件等方案。

有关详细信息，请参阅 ASP.NET Core 文档。

选择一种方案并了解微软的投资

生成面向Windows的应用的框架选项太多！如何确定

Windows是一个支持许多技术的开放平台。 下面是一些可帮助你选择平台的条件：

  • 你在构建的项目是优先支持Windows还是跨平台？
  • 你已有哪些语言或技能 — .NET、JavaScript，还有什么内容？
  • 是否需要访问特定于Windows的 API？
  • 哪种框架的功能最符合应用的要求？
  • 有关其他比较因素，请参阅 此表 。

对于许多业务应用，团队通常根据现有技能以及团队最舒适的使用方式进行选择。

我如何选择我的 Web 应用的最佳开发方法？

为 Web 应用选择开发方法时，请考虑以下事项：

  • 建议使用 Blazor 生成具有.NET的前端 Web 应用。 它允许你使用.NET生成前端和后端，从而节省时间和成本，这尤其适用于企业应用。
  • 如果要利用现有的 JavaScript 技能或需要与已建立的 JS 库或框架集成，JavaScript web apps仍然有意义。
  • 使用旧框架（如 Web 窗体、MVC 或 Razor Pages）的现有应用仍受支持，可以继续开发和维护。
谁正在使用 WinUI 3 生成应用？

Microsoft 照片是一个有据可查的例子。 应用从 UWP 迁移到Windows 应用 SDK，并继续使用 WinUI 3。 有关体系结构和迁移的详细信息，请参阅Microsoft照片：从 UWP 迁移到Windows 应用 SDK。

如今谁在构建.NET MAUI应用？

组织使用.NET MAUI为 Android、iOS、macOS 和 Windows构建跨平台应用。 请参阅.NET客户展示中的示例。

谁正在构建 WPF 应用程序？

大多数Microsoft Visual Studio UI 都是使用WPF生成的。 Visual Studio IDE 本身是复杂高性能WPF应用的主要示例。

谁正在构建 Blazor 应用？

GE Digital 的 FlightPulse 航空公司系统使用 Blazor 进行飞行员看到的后端配置，直接将传感器数据和分析引入飞行员，以提高安全性和效率。

在 .NET 网站上查看更多 Blazor 客户案例。

语言选择 （.NET vs C++）

我应该对Windows应用使用 C# 或 C++ 吗？

在大多数情况下，请使用 C# （.NET）。 C# 提供更快的开发、内存安全、丰富的库和出色的工具。 大多数Windows应用（包括 WinUI 3、WPF、WinForms 和 .NET MAUI 应用）最好是使用 C# 构建的。

如果需要直接访问硬件、最少的运行时开销或与现有 C++ 代码库的互操作，请使用 C++。 常见的 C++ 方案包括游戏引擎（DirectX）、驱动程序、系统级实用工具和性能关键组件。

因子 C# （.NET） C++
开发速度 ✅ 更快 — 托管内存、丰富的生态系统 ⚠️ 速度较慢 — 手动资源管理
运行时性能 ✅ 对现代 .NET 提供出色支持（AOT、Span<T>） ✅ 最佳情况 — 无 GC 暂停
内存安全 ✅ 垃圾回收 ⚠️ 手动 — 泄漏和漏洞风险
Windows API 访问 ✅ 通过 C#/WinRT 投影 ✅ 通过 C++/WinRT 投影
WinUI 3 支持 ✅ 完全支持 ✅ 通过 C++/WinRT 提供完全支持
跨平台 ✅.NET在 Windows、Linux、macOS 上运行 ✅ 采用平台特定代码
最适用于 业务应用、CRUD、服务、UI 密集型应用 游戏， 驱动程序， 系统工具， 低延迟

还可以混合使用：在 C# 中生成应用，并通过 P/Invoke（CsWin32） 或 C++/WinRT 组件调用性能关键型本机代码。

如何从 C# 调用 Win32 API？

使用 CsWin32，一个源生成器，用于在生成时创建类型安全的 P/Invoke 签名。 添加 Microsoft.Windows.CsWin32 NuGet 包，列出文件中所需的 NativeMethods.txt API，并通过生成的 PInvoke 类调用它们。

CsWin32 取代手动编写的[DllImport]声明，并在任何 C# 项目中工作，包括 WinUI 3、WPF、WinForms 和控制台应用。 有关分步演练，请参阅从 C# Windows应用（CsWin32）调用 Win32 API。

什么是 C++/WinRT，何时应使用它？

C++/WinRT 是Windows 运行时 API 的标准 C++17 语言投影。 在 C++ 中生成使用或创作 WinRT API 的Windows应用时使用它。 它将替换 C++/CX 和 Windows 运行时 C++ 模板库（WRL）。

在以下情况下选择 C++/WinRT：

  • 正在生成 C++ WinUI 3 应用
  • 你需要编写供其他语言使用的 Windows 运行时 组件
  • 你正在从 C++/CX 移植
什么是 C#/WinRT，何时需要？

C#/WinRT 为 C# 提供 WinRT 投影支持。 在大多数情况下，你不会直接与它交互 — .NET面向Windows的应用通过目标框架名字对象（TTFM）自动访问 WinRT API。 在 C# 中创作Windows 运行时组件或为第三方 WinRT 组件生成互操作程序集时，需要显式使用 C#/WinRT。

打包、部署和更新

打包、解压缩和打包到外部位置的应用之间有何区别？

打包的应用在包（如 MSIX）中包含其文件、标识和部署信息。 未打包的应用使用Windows包系统外部的安装程序或部署过程，默认情况下没有包标识。 采用外部位置打包的应用使用一个小型标识包，同时保留位于外部的二进制文件及其现有的安装程序和更新流程。

有关要求和权衡，请参阅 打包概述 。

是否需要包标识？

这取决于应用使用的Windows功能。 打包后台任务、共享目标、启动任务、自定义上下文菜单包扩展、基于清单的文件类型和协议关联以及许多Windows AI API 等方案都需要包标识。 Windows 应用 SDK推送通知支持没有标识的有限前台方案，但后台传送和 COM 激活需要标识。 WinUI 3 和本地应用通知可以在没有包标识的情况下工作。

请参阅需要包标识的功能。 如果需要标识，但必须保留现有安装程序，请考虑采用外部位置打包。

依赖于框架的部署与独立部署有何区别？

依赖框架的应用使用Windows 应用 SDK设备上单独安装的运行时包。 这会减少应用的部署大小，并允许已安装的框架接收服务更新。 自包含应用附带了其Windows 应用 SDK依赖项，这会增加部署大小，并使应用发布者负责使用新应用版本分发Windows 应用 SDK服务更新。

依赖于其他 MSIX 包（例如 Singleton 包）的 API 可能需要单独的部署或运行时支持检查，即使在独立应用中也是如此。 打包和运行时部署是单独的决策。 请参阅 Windows 应用 SDK 部署概述。

我的 WinUI 3 应用会为最终用户自动更新吗？

WinUI 3 应用可以通过Microsoft Store、.appinstaller文件或 MSI 或安装程序可执行文件传递。 应用商店包可以通过Microsoft Store服务进行更新，具体取决于应用商店和组织设置。 仅当 .appinstaller 部署的 UpdateSettings 配置了启动时检查或后台检查时，该部署才支持自动更新。 MSI 和设置部署必须提供或集成自己的更新机制。

我能否在不使用 MSBuild 的情况下使用 Windows 应用 SDK？

是的，在某些情况下。 WinUI 3 XAML 项目当前需要 MSBuild，尽管Visual Studio不是必需的，并且可以dotnet build从命令行调用 MSBuild。 可以在 C++ 和 CMake 项目中，通过预览版 Windows 应用 Development CLI 使用非 XAML 的 Windows 应用 SDK API，或者手动集成运行时。

Windows 人工智能

如何在 Windows AI API、Foundry Local 和 Windows ML 之间进行选择？

前三种技术是Windows Microsoft Foundry 的一部分。 可以将它们彼此组合在一起，并在同一应用中与云模型结合使用：

  • 使用 Windows AI APIs 获取开箱即用的功能，其模型和硬件加速由 Windows 管理。
  • 使用 Foundry Local 在本地发现、下载和运行支持的开源语言和语音模型。
  • 使用 Windows ML 通过适用于可用 CPU、GPU 和 NPU 硬件的执行提供程序运行自己的 ONNX 模型。
  • 如果需要云托管模型、检索、集中式治理或目标设备上不可用的功能，请使用 Microsoft Foundry（一个独立的云 AI 平台）。

比较“选择Windows AI 解决方案”中的选项。 考虑模型功能、隐私、连接、延迟、硬件覆盖范围、部署大小和运营成本。

Windows AI 功能是否需要AI+ PC？

不是全部。 许多Windows AI API 需要AI+ PC，但某些 API 还支持特定的 GPU 或 CPU。 Foundry Local 和 Windows ML 支持更广泛的硬件配置，受其当前的操作系统、模型、运行时和执行提供程序要求的约束。

检查Windows AI API 硬件表以及特定 API 或模型的要求。 在运行时检测是否受支持以及模型是否已就绪，并在功能不可用时提供非 AI、本地模型或云端回退方案。

Windows AI 功能是否可以在本地和脱机运行？

是的。 Windows AI API、Foundry Local 和 Windows ML 可以在用户的设备上运行推理，从而降低延迟并将输入数据保持本地。 某些模型或执行提供程序必须首先下载或预配，并且可能需要在设置或服务期间建立 Internet 连接。 云 AI 服务需要连接，并根据数据处理条款将数据发送到服务。

告知用户何时需要下载模型，以及何时数据会离开设备。 在测试其完整的首次运行、更新和回退体验之前，请勿将功能描述为支持脱机的功能。

AI 工具能否帮助生成或现代化Windows应用？

是的。 AI 编码代理可以帮助搭建基架项目、解释 API、迁移代码、生成测试和诊断生成问题。 使用 AI 辅助的 Windows 开发指南，获取有关 GitHub Copilot、WinUI 代理插件、Microsoft Learn MCP 服务器、迁移工作流和 AI 辅助测试的指导。

查看并测试生成的代码，就像你所做的任何其他贡献一样。 具体而言，请验证 API 名称和版本、包功能、安全敏感代码、辅助功能以及任何 UWP 到 WinUI 3 替换。

在交付 AI 辅助功能之前，应考虑什么？

定义该功能的预期用途和限制、使用代表性数据评估质量和安全、在适当情况下披露 AI 行为、保护用户数据，并在模型或所需硬件不可用时提供回退。 将机密和特权服务凭据从客户端应用中保留，并要求用户确认，然后才能执行后果性或不可逆转的操作。 请参阅Windows 上负责任的生成式 AI 开发和面向 Windows 开发的安全性与负责任的 AI。

性能和优化

如何使我的Windows应用对最终用户感觉很好？

请参阅 Windows 应用程序开发 - 最佳做法和 Windows 应用性能和基础知识概述。

Compatibility

我的用户是否必须更新Windows才能使用 WinUI 3 应用？

Windows 应用 SDK的最低兼容 OS 为 Windows 10 版本 1809，内部版本 17763。 要获得 Microsoft 支持，需要使用受支持的 Windows 应用 SDK 发布版本及其最新维护更新，并且所使用的 Windows 版本、发行版本和维护通道仍在支持范围内。 单个 API 可能需要较新的Windows版本或特定硬件。 请参阅Windows 应用 SDK支持和发布频道。

我的 WinUI 3 应用可以以 Arm64 为目标吗？

是的。 构建本机 Arm64 应用，以获得最佳性能和效率。 对于具有 x64 依赖项的大型 C++ 代码库， Arm64EC 允许以增量方式迁移模块。 arm 上的Windows 11还可以通过 Prism 仿真运行许多现有的 x86 和 x64 应用，但你应该在具有代表性的 Arm 设备上测试性能和兼容性。

弃用和迁移

是否弃用了 UWP/WinUI for UWP？

UWP 和 WinUI 2 未正式弃用。 Visual Studio 2026 支持结合现代 .NET 和 Native AOT 的 UWP，而 WinUI 2.8 仍然是面向 UWP 的最新稳定版 WinUI。 但是，Microsoft建议使用 WinUI 3 和 Windows 应用 SDK，以使用新的常规用途Windows桌面应用。

面向新式 .NET 的 UWP Native AOT 支持现已正式可用，并且在 Visual Studio 2026 中是默认的 C# UWP 项目类型。 将现有 UWP 应用从 .NET Native 迁移到现代 .NET，是一个独立于将其 UI 迁移到 WinUI 3 的现代化步骤。 请参阅使用 .NET 和本机 AOT 实现 UWP 应用的现代化。

何时应将 UWP / WinUI for UWP 应用迁移到 WinUI 3？

如果 UWP 开发人员对 UWP 及其功能集感到满意，则不应感到迁移压力 — 对于许多应用，正确的选择可能是留在 UWP 上。

想要从最新的Windows平台和.NET投资中受益的应用应考虑迁移到 WinUI 3 和Windows 应用 SDK。 请参阅从 UWP 迁移到 Windows 应用 SDK。

什么时候我不应将 UWP + WinUI for UWP 应用迁移到 WinUI 3？

如果你的目标设备或应用模型要求使用 UWP，则继续使用 UWP，例如 Xbox 应用、HoloLens 2D 应用，或适用于标准 Surface Hub 环境的应用。 Windows IoT Enterprise 支持桌面应用技术，包括Windows 应用 SDK，因此 IoT 目标本身并不是使用 UWP 的原因。

WPF已弃用？

否。 WPF 仍受支持，并在现代 .NET 中持续获得功能、性能、辅助功能和 Fluent 风格方面的改进。 对于现有WPF应用和符合WPF的新应用，它仍然是一个不错的选择。 对于新的常规用途Windows桌面应用，Microsoft的主要建议是 WinUI 3，其中包含Windows 应用 SDK。 请参阅 GitHub 上的 WPF 路线图。

WinForms 是否弃用？

否。 WinForms 受支持并继续接收功能更新。 请参阅 GitHub 上的 Windows 窗体 路线图。

是否弃用了 Windows 运行时 (WinRT)？

否。 WinRT 是一个应用程序二进制接口（ABI），可跨多种语言进行互作。 WinRT 是 COM 的演变，Windows 应用 SDK通过 WinRT API 提供其大部分功能。

发行说明

在哪里可以找到 Windows 应用 SDK 的发行说明？

请参阅Windows 应用 SDK发行说明，了解稳定、预览和实验性版本。 面向Windows开发人员的新增功能页面总结了最新的Windows SDK、Windows 应用 SDK、WinUI 3、工具和平台更新。

相关内容

  • Last updated on