包裝概述

封裝定義了你的應用程式如何安裝、更新並整合到 Windows。 WinUI 3 應用程式預設是打包,而許多桌面應用程式,如傳統 Win32 應用程式,則是未打包執行。 選擇打 式或 非打包 式應用程式會影響你能使用的功能、依賴的部署模式,以及客戶整體體驗。

備註

正在打造新的 WinUI 3 應用程式嗎? 你已經預設被打包了。 以下指引對於需要明確做出選擇的開發者尤其相關——通常是在移植現有應用程式、部署到企業機器,或為未包裝的應用程式新增 Windows 功能時。

為什麼應用程式包裝很重要

打包式應用程式享有乾淨的安裝模式、自動更新,以及需要套件身份的 Windows 功能存取權——包括背景任務、通知、右鍵選單擴充、共享目標及其他擴充點。 封裝也有助於透過 Microsoft Store 及企業部署工具等管道,確保部署更乾淨、更新可靠,以及分發流程的簡化。

需要套件身分識別的功能

許多 Windows 功能僅適用於具有封裝識別的應用程式,無論是透過完整的 MSIX 封裝,還是使用外部位置封裝(稀疏封裝)。 範例包括背景任務、推播通知、分享目標、自訂右鍵選單擴充功能、基於清單的檔案類型與協定關聯,以及 Windows AI API。

完整清單請參見 需要套件身份的特徵

小提示

如果你未封裝,呼叫 Windows API 時遇到 E_ILLEGAL_METHOD_CALLAPPMODEL_ERROR_NO_PACKAGE 錯誤,那就是套件身份的要求。 請將 帶有外部位置的包裝(稀疏包裝) 視為摩擦最小的解決方案。

要在執行時偵測你的程序是否有套件身份,請使用 GetCurrentPackageFullName。 請參閱 Inside MSIX 部落格的「 這是封裝程序嗎?」 ,關於標準的 C++ 和 C# 範例。

包裝模型一覽

型號 套件身分識別 安裝程式 商店合格資格 最適合用於
封裝型(MSIX) ✅ 是 MSIX 取代安裝程式 ✅ 是的(MSIX 提交) 新應用程式、商店發佈、企業版 MDM
包裝與外部位置 ✅ 是 你現有的安裝程式 ✅ 是的(MSI/EXE 提交) 現有安裝程式的應用程式和獨立軟體開發商(ISV)
未包裝 ❌ 否 MSI 或 EXE 安裝程式(也包括:XCopy 或非 Store 發行版的腳本) ✅ 是的(MSI/EXE 提交 — 需要支援靜默安裝的 MSI 或 EXE 安裝程式) 廣泛的 Win32 發行版與內部工具

封裝應用程式(MSIX)

封裝應用程式使用 MSIX,並具備 package 身份碼,這是許多Windows擴充點所必需的。 套件身份讓 Windows 能夠可靠地識別平台 API 的呼叫者,這也是為什麼這些功能依賴它。

  • 打包後的應用程式通常運行於輕量級應用程式容器中,具備檔案系統與登錄檔虛擬化功能(舊版應用程式及 MSIX AppContainer 應用請參見 AppContainer)。
  • 如果需要,應用程式也可以設定為不在應用程式容器中執行。
  • MSIX 用於封裝與安裝(參見 What is MSIX?)。

帶有外部定位的包裝(稀疏包裝)

帶有外部位置的打包(也稱為 稀疏套件)讓你能在現有應用程式旁邊註冊一個小型身份套件——而不必更改安裝程式、二進位位置或更新流程。 它於 Windows 10 2004 版本(建置 19041)中首次亮相。

這是現有 Win32/WPF/WinForms 應用程式的最佳選擇,這些應用程式是透過自家安裝程式(NSIS、WiX、InstallShield 等)提供,且不想用 MSIX 取代。 你註冊一個輕量級身分識別套件,二進位檔保持在原位,並解鎖完整的以套件身分識別為門檻的 Windows 功能。

能力 MSIX 外部地點
更換您的安裝程式 是的 No
套件內的二進位文件 是的 沒有(外部)
商店合格資格 是的(MSIX 提交) 是的(MSI/EXE 提交)
套件身分識別 是的 是的
更新機制 MSIX 更新 你現有的機械裝置

完整指引:透過封裝和外部位置來授予封裝身份

未封裝應用程式

未封裝的應用程式不使用 MSIX, 也沒有套件識別碼,這表示他們無法存取上述功能。

  • 它們在 API 界面、檔案系統存取、登錄存取、權限提升及進程模型方面保持完全無限制。
  • 安裝與更新依賴 .exe.msi、自訂安裝程式、ClickOnce 或 xcopy 部署。

在你決定是否採用無包裝之前,請先根據 上方的功能表 與你的路線圖對照。 如果通知、背景任務或 AI API 即將推出,考慮先從打包式開始。

依情境選擇

Scenario 推薦型號 詳細資料
獨立開發者發佈到 Microsoft Store 建議使用封裝(MSIX) MSIX 是推薦路徑——它能啟用商店管理的更新、差異式下載和乾淨卸載。 WinUI 3 應用程式預設是打包的。 代碼簽章由商店免費處理。發佈你的打包應用程式

擁有現有 MSI 或 EXE 安裝程式的 Win32 應用程式,也可以透過 MSI/EXE 提交路徑發佈到商店,但商店不會向現有使用者推送更新——更新必須由應用程式或安裝程式自行處理。
企業應用程式透過 Intune 或 設定管理員 部署 封裝式或現有安裝程式的外部位置 新應用程式應該使用 MSIX。 自帶安裝程式的現有應用程式可以使用以外部位置為基礎的封裝。 Code signing: 使用自簽憑證(透過 Intune、群組政策或 設定管理員 信任)或 Azure Artifact Signing(前稱為 Trusted Signing)。 → 部署封裝應用程式
ISV 會提供其自家安裝程式的直接下載。 包裝與外部位置 在現有安裝程式旁註冊一個輕量級身份套件。 程式碼簽署: 非 Store 發佈需要 CA 信任的憑證。 Azure Artifact Signing(前稱 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 Forms(WinForms)——那麼你可以使用 MSIX 來打包並部署你的應用程式。

從舊有安裝程式遷移到 MSIX

如果你的應用程式目前使用舊有安裝程式,你可以遷移到 MSIX 以取得乾淨安裝/卸載、自動更新、商店發行及套件識別。 遷移路徑取決於你目前的安裝技術,以及你是否能取得原始碼。

現任安裝商 建議的移轉路徑 需要原始碼嗎?
MSI(Windows 安裝程式) 使用 MSIX 封裝工具直接將 MSI 轉換成 MSIX。 可處理大多數 MSI 模式,包括自訂動作。 No
ClickOnce (.NET) 使用 Visual Studio MSIX 封包專案從原始碼重建。 ClickOnce 的自動更新可以用商店更新或應用程式安裝程式取代。 是的
InstallShield / 進階安裝程式 使用 MSIX 封包工具在乾淨的虛擬機上擷取安裝。 複雜的自訂操作可能需要在套件編輯器中手動修正。 No
Inno Setup / NSIS 請使用 MSIX 封包工具的虛擬機擷取工作流程。 在工具的乾淨環境中執行 EXE 安裝程式。 No
App-V(虛擬套件) 直接使用 MSIX 封包工具轉換——它支援 App-V 5.x 套件作為輸入。 No
MSIX 需修改 使用 Package Support Framework 來套用執行時修正(檔案/登錄檔重定向),而不更改你的應用程式程式碼。 No

小提示

對於有複雜安裝程式、核心驅動程式、以 SYSTEM 執行服務,或是 MSIX 不支援的全機 COM 註冊的應用程式,可以考慮使用 MSIX 搭配外部位置 (也以外部位置包裝)。 這樣你就能為 Windows 功能提供套件身份,同時對於需要提升權限的元件則使用傳統安裝程式。 請參閱 透過使用外部位置進行封裝來授與套件身分識別

重要考慮

  • 在乾淨的虛擬機上測試 — MSIX 封裝工具會擷取安裝過程中的所有變更。 請在乾淨的 Windows 映像檔上執行,以避免擷取無關的系統變更。
  • 套件支援框架 — 如果你轉換後的應用程式在執行時有問題(檔案路徑假設、登錄檔寫入 HKLM),套件 支援框架 可以在不修改原始碼的情況下修正這些問題。
  • 與舊有安裝程式並行 部署 — 你可以在轉換期間同時部署 MSIX 版本與舊有安裝程式。 規劃明確的設定/資料遷移(例如首次執行時匯入),因為 MSIX 和 MSI/EXE 安裝時的套件識別碼和儲存位置不同。

其他安裝技術