打包概述

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

注释

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

应用打包为何重要

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

需要包标识的功能

很多 Windows 功能仅在具有包标识的应用中工作，无论是通过完整 MSIX 打包还是使用外部位置打包（稀疏打包）。 示例包括后台任务、推送通知、共享目标、自定义上下文菜单扩展、基于清单的文件类型和协议关联以及Windows AI API。

有关完整列表，请参阅 需要包标识的功能。

小窍门

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

若要在运行时检测进程是否具有包标识，请使用 GetCurrentPackageFullName。 有关 canonical C++ 和 C# 示例，请参阅 Inside MSIX 博客中的这是打包进程吗？。

打包模型一览

型号 包标识 安装程序 存储符合条件的 最适用于
封装（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 工作，但某些功能不可用。

小窍门

代码签名要求和成本因分发路径而异。 有关选项的完整细分，请参阅适用于Windows应用开发人员的代码签名选项。

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

与打包模型分开，使用Windows 应用 SDK的应用选择如何携带其运行时依赖项：依赖于框架（Windows 应用 SDK运行时安装在用户的计算机上）或自包含（所有Windows 应用 SDK二进制文件随应用一起提供）。 此选择与打包方式无关。

有关完整比较和部署指南，请参阅Windows 应用 SDK部署概述。

开始了解 MSIX

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

从旧安装程序迁移到 MSIX

如果应用当前使用旧版安装程序，则可以迁移到 MSIX 以获取干净安装/卸载、自动更新、应用商店分发和包标识。 迁移路径取决于当前的安装程序技术以及你是否有权访问源代码。

当前安装程序 建议的迁移路径 需要源代码？
MSI （Windows Installer） 使用 MSIX 打包工具 将 MSI 直接转换为 MSIX。 处理大多数 MSI 模式，包括自定义操作。 否
ClickOnce （.NET） 使用 Visual Studio MSIX 打包项目从源重新生成。 ClickOnce 自动更新可以替换为应用商店更新或应用安装程序。 是的
InstallShield / 高级安装程序 使用 MSIX 打包工具在干净的虚拟机上捕获安装过程。 复杂的自定义操作可能需要在包编辑器中手动修复。 否
Inno Setup / NSIS 使用 MSIX 打包工具的基于 VM 的捕获工作流。 在工具的干净环境中运行 EXE 安装程序。 否
App-V （虚拟包） 直接使用 MSIX 打包工具进行转换——它支持以 App-V 5.x 程序包作为输入。 否
需要修改的 MSIX 使用 包支持框架 应用运行时修补程序（文件/注册表重定向），而无需更改应用代码。 否

小窍门

对于安装程序较为复杂、包含内核驱动程序、具有以 SYSTEM 身份运行的服务，或需要 MSIX 不支持的面向整个计算机的 COM 注册的应用，请考虑带外部位置的 MSIX（使用外部位置打包）。 这样，就可以为Windows功能打包标识，同时对需要提升访问权限的组件使用传统安装程序。 请参阅通过使用外部位置进行打包来授予程序包标识符。

重要注意事项

  • 在干净的 VM 上进行测试 — MSIX 打包工具在安装过程中捕获所有更改。 在干净Windows映像上运行它，以避免捕获不相关的系统更改。
  • 包支持框架 - 如果转换后的应用存在运行时问题（文件路径假设、注册表写入 HKLM），则 包支持框架 可以在不修改源的情况下修复这些问题。
  • 与旧版安装程序并排 - 可以在过渡期间将 MSIX 版本与旧版安装程序一起部署。 规划显式设置/数据迁移（例如，首次运行时导入），因为 MSIX 和 MSI/EXE 安装包标识和存储位置不同。

其他安装技术

相关内容

  • Last updated on