打包概述

打包定义应用如何安装、更新和与Windows集成。 WinUI 3 应用默认打包，而许多桌面应用（如传统 Win32 应用程序）则运行未打包。 在 打包 或 解压缩 的应用之间进行选择会影响可以使用的功能、你依赖的部署模型以及客户获得的整体体验。

注释

生成新的 WinUI 3 应用？ 默认情况下，已为你打包。 以下指南最适用于需要做出明确选择的开发人员，通常是在移植现有应用、部署到企业计算机或将Windows功能添加到最初未打包的应用时。

应用打包为何重要

打包的应用受益于全新安装模型、自动更新和对需要包标识的Windows功能的访问权限，包括后台任务、通知、上下文菜单扩展、共享目标和其他扩展点。 打包还有助于确保更简洁的部署、可靠的更新，并通过Microsoft Store和企业部署工具等渠道简化分发。

需要包标识的功能

这些 Windows 功能仅在具有包标识的应用中工作 — 无论是通过完整 MSIX 打包还是使用外部位置打包（稀疏打包）。

功能 说明
后台任务 当应用不在前台时运行代码， 例如，同步数据、处理下载或响应系统事件。
Windows AI API （Phi 硅、OCR 等） 访问设备 AI 功能，例如本地语言模型、文本识别和图像分析。
推送通知（WNS，Windows通知服务） 通过Windows通知服务从云服务接收实时通知。
共享对象 让用户通过系统共享工作表直接将来自其他应用的内容共享到你的应用中。
自定义上下文菜单扩展 将应用的操作添加到文件资源管理器和其他 shell 图面中的右键单击菜单。
文件类型和协议关联 将应用注册为特定文件类型或 URI 协议的处理程序（例如，yourapp://）。
启动任务 当用户登录Windows时自动启动应用。
应用服务 公开其他应用可以调用的后台服务，从而启用应用间通信。

小窍门

如果在调用 Windows API 时解压缩并遇到 E_ILLEGAL_METHOD_CALL 或 APPMODEL_ERROR_NO_PACKAGE 错误，则这是包标识要求。 请参阅使用外部位置打包（稀疏打包）作为最低摩擦修复。

若要在运行时检测你的进程是否具有包标识，请使用 GetCurrentPackageFullName——请参阅 Inside MSIX 博客中的 这是已打包的进程吗？ 一文，其中提供了权威的 C++ 和 C# 示例。

有关详细信息，请参阅 需要包标识的功能。

打包模型一览

型号 包标识 安装程序 存储符合条件的 最适用于
封装（MSIX） ✅ 是 MSIX 替换安装程序 ✅ 是（MSIX 提交） 新应用、应用商店发布、企业 MDM
使用外部位置打包 ✅ 是 现有安装程序 ✅ 是（MSI/EXE 提交） 具有自己安装程序的现有应用程序，以及独立软件供应商（ISV）
解压缩 ❌ 否 MSI 或 EXE 安装程序（另外，对于非应用商店分发，可使用 XCopy 或脚本） ✅ 是（MSI/EXE 提交 - 需要具有无提示安装支持的 MSI 或 EXE 安装程序） 广泛的 Win32 分发版，内部工具

打包的应用 （MSIX）

打包的应用使用 MSIX，并且具有 包标识，这是许多 Windows 扩展点所必需的。 包标识允许Windows可靠地标识平台 API 的调用方，这就是为什么这些功能依赖于它的原因。

使用外部位置打包（稀疏打包）

使用外部位置（也称为 稀疏包）打包可将小型标识包与现有应用一起注册，而无需更改安装程序、二进制位置或更新过程。 它已在 Windows 10 版本 2004（内部版本 19041）中引入。

这是现有 Win32/WPF/WinForms 应用的甜蜜点，这些应用通过其自己的安装程序（NSIS、WiX、InstallShield 等）分发，不想用 MSIX 替换它。 注册一个轻量级身份包，二进制文件保持在原位，从而可以解锁完整的以包身份限定的 Windows 功能集。

能力 MSIX 外部位置
替换你的安装程序 是的 否
包内的二进制文件 是的 否（外部）
存储符合条件的 是（MSIX 提交） 是（MSI/EXE 提交）
包标识 是的 是的
更新机制 MSIX 更新 现有机制

→ 完整演练：通过使用外部位置打包授予包标识

未打包的应用

未打包的应用不使用 MSIX， 并且没有包标识，这意味着它们无法访问上面列出的功能。

  • 在 API 接口、文件系统访问、注册表访问、权限提升和进程模型方面，它们仍然完全不受限制。
  • 安装和更新依赖于 .exe、.msi、自定义安装程序、ClickOnce 或 xcopy 部署。

在决定使用未打包方案之前，请根据您的路线图检查上面的功能表。 如果通知、后台任务或 AI API 即将推出，请考虑从打包开始。

按情景选择

情景 建议的模型 详细信息
独立开发者发布到 Microsoft Store 推荐使用打包 (MSIX) MSIX 是推荐的途径——它支持由商店管理的更新、差异下载和干净卸载。 WinUI 3 应用默认打包。 代码签名由应用商店免费处理。 → 分发打包的应用

具有现有 MSI 或 EXE 安装程序的 Win32 应用也可以通过 MSI/EXE 提交路径发布到应用商店，但应用商店不会向现有用户推送更新 - 应用或安装程序必须处理更新。
通过 Intune 或 Configuration Manager 部署的 企业应用 打包，或现有安装程序的外部位置 新应用应使用 MSIX。 具有自己安装程序的现有应用可以使用外部位置打包。 代码签名：使用自签名证书（通过 Intune、组策略或 Configuration Manager 信任）或 Azure 工件签名（以前称为受信任签名）。 → 部署打包的应用
ISV 提供包含自身安装程序的直接下载 使用外部位置打包 将轻型标识包与现有安装程序一起注册。 代码签名： 非应用商店分发需要 CA 信任的证书。 Azure 工件签名（前称 Trusted Signing)是推荐的更低成本选项。 → 授予包标识

或者，通过 MSI/EXE 提交路径将现有安装程序提交到应用商店。
内部工具或开发人员实用工具 未包装的 最简单的构建和部署。 Windows 应用 SDK通过 NuGet 工作，但某些功能不可用。

小窍门

您不确定代码签名成本吗？ 通过 Microsoft Store 发布 MSIX 包意味着无需单独获取或管理最终用户信任的证书 - Microsoft重新对包进行签名。 通过应用商店发布 Win32 MSI/EXE 安装程序，需要证书链接至 Microsoft 受信任根计划中的 CA；自签名的证书不被接受。 对于其他分发路径，签名方法取决于部署上下文 — 企业环境可以通过设备管理信任自签名证书，而更广泛的非应用商店分发通常需要 CA 信任的代码签名解决方案。 Azure项目签名（以前受信任的签名）是Microsoft的建议选项（请参阅 pricing），无需硬件令牌。

依赖于框架的部署与自包含部署

与打包模型分开，使用Windows 应用 SDK的应用选择如何携带其运行时依赖项：

  • 依赖于框架：必须在用户的计算机上安装 Windows 应用 SDK 的运行时。 更小的应用占用空间；依赖运行时存在或自动安装。
  • 自包含：所有Windows 应用 SDK二进制文件随应用一起提供。 占用空间较大;没有外部运行时要求。 适用于安全防护严密的企业环境。

→ 部署独立应用

开始了解 MSIX

如果生成 Win32 桌面应用（有时称为 classic 桌面应用）或.NET应用（包括Windows Presentation Foundation（WPF）和Windows 窗体（WinForms），则可以使用 MSIX 打包和部署应用。

其他安装技术

相关内容

  • Last updated on