Windows 應用程式 SDK 部署概覽

你可以用兩種方式部署 Windows 應用程式 SDK：

  • 依賴框架。 你的應用程式需要依賴目標機器上是否存在 Windows 應用程式 SDK 執行環境和/或 Framework 套件。 依賴框架的部署是 Windows 應用程式 SDK 的預設部署模式，以有效利用機器資源與可維護性。
  • 獨立式。 你的應用程式會隨附 Windows 應用程式 SDK 相依性，因此無須在目標電腦上另外安裝獨立的執行階段。

本主題也會使用 封裝應用程式、具有外部位置的封裝應用程式，以及 未封裝的應用程式。 關於這些術語的說明，請參閱 套件與部署概述。

部署架構相依 部署獨立式
優點 小型部署。 只會散發您的應用程式及其其他相依檔案。 Windows 應用程式 SDK 執行環境與框架套件由已封裝的框架相依應用程式自動安裝；或者作為 Windows 應用程式 SDK 執行環境安裝程式的一部分由封裝在外部位置或未封裝的框架相依應用程式進行安裝。

可用的。 Windows 應用程式 SDK 的服務更新可透過 Windows 應用程式 SDK Framework 套件自動安裝，無需應用程式操作。		 Control Windows 應用程式 SDK 版本。 你可以控制 Windows 應用程式 SDK 的哪個版本隨你的應用程式一起部署。 除非您重建並重新發佈應用程式，否則 Windows 應用程式 SDK 的維護更新不會影響到您的應用程式。

與其他應用程式隔離。 應用程式和使用者無法在不卸載整個應用程式的情況下解除安裝你的 Windows 應用程式 SDK 依賴。

Xcopy 部署。 由於 Windows 應用程式 SDK 的相依性由你的應用程式承載，你可以直接將建置輸出轉載來部署應用程式，無需額外安裝需求。
缺點 額外的安裝相依性。 需要安裝 Windows 應用程式 SDK 執行時及/或 Framework 套件，這會增加應用程式安裝的複雜度。

共用相依性。 共同使用的相依性被卸載的風險。 卸載共用元件的應用程式或使用者可能會影響其他共用相依性之應用程式的用戶體驗。

相容性風險。 有風險在維護 Windows 應用程式 SDK 更新時引入破壞性變更。 雖然維護更新應該提供回溯相容性，但可能會引進回歸。		 大型部署（僅限未封裝的應用程式）。 由於你的應用程式包含 Windows 應用程式 SDK，所需的下載容量和硬碟空間會比依賴框架版本大。

效能（僅限未封裝的應用程式）。 載入速度較慢，而且會使用更多記憶體，因為代碼頁不會與其他應用程序共用。

無法服務。 隨應用程式附帶的 Windows 應用程式 SDK 版本只能透過釋出新版本來更新。 你負責將 Windows 應用程式 SDK 的服務更新整合進你的應用程式中。

另請參閱建立並執行 WinUI 3 專案，並在現有專案中使用 Windows 應用程式 SDK。

Note

PublishSingleFile （單檔 EXE）支援未封裝、自包含的 WinUI 3 應用程式（Windows 應用程式 SDK 1.5 及更新版本）。 封裝應用程式及依賴框架的應用程式不支援 PublishSingleFile。 請參閱 單檔案 EXE 以了解所需的 MSBuild 屬性。

架構相依部署的詳細資訊

在配置依賴框架的應用程式以進行部署前，若想了解應用程式使用 Windows 應用程式 SDK 時所依賴的相依性，請先檢視 Windows 應用程式 SDK 的部署架構。

已封裝的應用程式

如果你選擇使用依賴框架的打包應用程式（參見「套件與部署概述」），以下是如何與該應用程式一起部署 Windows 應用程式 SDK 執行環境的說明：

使用外部位置或未封裝的應用程式封裝

如果你選擇使用依賴框架的套件應用程式（帶有外部位置），或是依賴框架的非封裝應用程式（參見「套件與部署概述」），以下是如何隨應用程式部署 Windows 應用程式 SDK 執行環境的說明：

獨立式部署的詳細資訊

請參閱 Windows 應用程式 SDK 自包含應用程式部署指南。

Note

PublishSingleFile（單檔 EXE）要求應用程式必須同時為 未封裝 且 自我包含。 請參閱 單檔 EXE 以了解完整的 MSBuild 屬性清單。

初始化 Windows 應用程式 SDK

你應該如何初始化 Windows 應用程式 SDK，取決於你是否以及如何打包你的應用程式;以及你部署時相對於 Windows 應用程式 SDK 執行環境的方式。 使用適用於您應用程式的下面部分。

已封裝的應用程式

您的應用程式部署方式 如何初始化
架構相依 請參閱 呼叫部署 API。
自成一體 不需要初始化。

解除封裝的應用程式，以及使用外部位置封裝的應用程式

您的應用程式部署方式 如何初始化
架構相依 請參閱 在封裝外部位置或解除封裝的應用程式中使用啟動載入器 API。
自成一體 請參閱 退出或選擇加入自動 UndockedRegFreeWinRT 支援功能。

架構考量（x64，ARM64）

部署應用程式時，必須為使用者所需的每種處理器架構包含二進位檔。 這適用於依賴框架的部署模式和自包含的部署模式。

ARM64 支援

ARM 裝置上的 Windows（包括 Surface Pro X、Surface Pro 11 和 Copilot+ PCs）原生執行 ARM64。 雖然 x64 模擬可在 Windows 11 ARM64 裝置上使用，但原生 ARM64 二進位檔提供更佳的效能與電池續航力——當你希望在 Copilot+ PCs 上獲得最佳裝置 AI 工作體驗時，這是推薦的。

原生 ARM64 部署

  • MSIX 套件組合 — 建立一個.msixbundle，其中包含 x64 和 ARM64 兩種架構。 當你為多個平台建置時，Visual Studio 會自動產生這些資料。 商店和應用程式安裝程式會在安裝時選擇正確的架構。

  • 自包含發佈 — 為每種架構指定執行時識別碼（RID）：

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT — 在您的 Visual Studio 解決方案中，為 x64 和 ARM64 建立個別的組態。

  • 依賴框架的應用程式 — 使用Windows 應用程式 SDK執行時安裝程式時，請確保提供正確的架構專用安裝程式。 Windows 應用程式 SDK 會為 x64 和 ARM64 提供獨立安裝程式。

Arm64EC — 針對大型 C/C++ 程式碼庫的漸進遷移

如果你的應用程式有龐大的原生（C/C++）程式碼庫，一次性完全重新編譯到 ARM64 可能不太實際。 Arm64EC （Emulation Compatible）允許你在同一過程中混合 x64 和 ARM64 程式碼。 你會將效能關鍵的模組重新編譯成原生 ARM64，而剩下的 x64 模組則在模擬下執行——全部都在單一的二進位檔中。

Approach 最適合用於 取捨
完整版 ARM64 重新編譯 純 .NET 應用程式，小型 C++ 專案 最佳效能；要求所有相依項目都必須與 ARM64 相容
Arm64EC 大型 C/C++ 應用程式、僅支援 x64 的插件或第三方 DLL 的應用程式 增量遷移;模擬部分的運行速度比原生還慢
僅限 x64（模擬） 無法重新編譯且不需要最高效能的應用程式 最簡單;ARM64 裝置的電池續航力降低與延遲增加

欲了解更多資訊，請參閱 Arm64EC — 用於 Arm 原生效能的建置與移植應用程式。

仿真（Prism）

ARM 版的 Windows 11 使用名為 Prism 的模擬層，在 ARM64 硬體上執行 x64 和 x86 應用程式。 Prism 在執行時將 x86/x64 指令轉譯為 ARM64，提供廣泛的應用程式相容性，且不需重新編譯。

  • x64 模擬 — 僅支援 Windows 11 ARM64 裝置（不支援 Windows 10 on ARM）。
  • x86 模擬 — 支援 Windows 10 與 Windows 11 ARM64 裝置。
  • 效能 — 模擬應用程式通常能以可接受的效能來滿足生產力工作負載，但圖形密集或運算密集的應用程式，原生 ARM64 或 Arm64EC 架構會帶來顯著效益。

小提示

如果你只針對 x64，你的應用程式仍能透過 Prism 模擬在 ARM64 裝置上運行（僅限 Windows 11）。 然而，強烈建議原生 ARM64 版本用於生產應用程式——模擬應用程式耗電較多且延遲較高。 在 Copilot+ PCs 上，原生 ARM64 能為裝置上的 AI 工作負載提供最佳效能。

提交至市集時，請上傳特定架構的套件，或上傳同時包含兩者的套件組合。 商店只會將對應的架構提供給每個裝置。

  • Last updated on