如何一步一步建立 MSIX 包,避免意外狀況

最後更新: 02/12/2025
作者: 艾薩克
  • MSIX 統一並現代化了應用程式打包方式 Windows,改善 可靠性卸載清理以及磁碟和頻寬效率。
  • MSIX 打包工具可讓您將舊式安裝程式(MSI、EXE、App-V、ClickOnce、腳本)轉換為 MSIX 套件,前提是已準備好乾淨且受控的擷取環境。
  • Visual Studio 直接從程式碼產生 MSIX,方便建立套裝組合和上傳檔案到 Store,並將驗證與 WACK 集成,並透過 Azure AD 自動提交。
  • 借助 MSIX 應用附加和 VHD/CIM 容器,可以將遠端桌面環境中的應用程式與基礎鏡像解耦,從而簡化版本控制和部署。

MSIX 套件建立指南

如果您從事 Windows 應用程式部署工作,遲早會遇到MSIX 格式。這種格式已成為微軟軟體打包的旗艦格式,如果您想避免在生產環境中出現各種問題,就必須了解如何正確且一致地建立 MSIX 套件。

接下來,您將找到一份全面的逐步指南,指導您如何準備環境、將傳統安裝程式轉換為 MSIX 格式、簽名、驗證和分發軟體包,無論您是使用 MSIX 打包工具、Visual Studio 還是命令列我們的目標是讓您在掌握重要技術細節的同時,獲得一個實用的概覽。

什麼是 MSIX?為什麼值得使用 MSIX?

MSIX基礎知識

MSIX 是適用於 Windows 的現代應用程式打包格式,它統一併改進了先前的 MSI、AppX 和 App-V 等技術。它不僅僅是「另一個安裝程式」:它增加了隔離性、更清晰的管理以及進階的本地和雲端分發選項。

主要優勢包括可靠的安裝和卸載(微軟報告的成功率超過 99,9%)、卸載應用程式時能夠保持系統“乾淨”,以及透過避免在多個應用程式之間重複通用檔案來減少磁碟空間使用量。

MSIX 旨在很好地適應現代場景:它優化了頻寬(64 KB 的資料區塊可從雲端分發),與 Microsoft Store、Intune 或 Configuration Manager 等管理工具集成,並且與MSIX 應用附加等技術相容,可用於遠端桌面環境和 Windows 365。

將傳統安裝程式(EXE、MSI、App-V、ClickOnce、腳本等)轉換為 MSIX 套件的主要工具是MSIX 打包工具,該工具可在 Microsoft Store 中找到,也可作為離線軟體包下載。此外,Visual Studio 還允許您直接從UWP 專案或 Windows 應用程式打包專案中的原始程式碼產生 MSIX 套件。

到達 MSIX 包的路徑

建立 MSIX 套件的方法

在開始轉換任何內容之前,最好先決定如何產生軟體包。根據您是否可以存取原始程式碼,不同的方法會更適合建立易於維護的 MSIX 軟體包

如果應用程式正在積極開發中,並且您可以控製程式碼,那麼理想的做法是在編譯過程中產生 MSIX:使用 Visual Studio(UWP 或 Windows 應用程式打包專案)或透過整合到建置系統(Azure DevOps、Jenkins 等)中的 MSIX 命令列工具。

但是,如果您必須處理已經編譯的舊式安裝程序(MSI、EXE、App-V 5.x、ClickOnce、自訂腳本…)或甚至是您沒有程式碼的應用程序,建議的方法是使用轉換電腦上的MSIX 打包工具來捕獲安裝並生成軟體包。

在桌面虛擬化和 WVD/Azure 虛擬桌面場景中,除了產生 MSIX 之外,通常還會將該套件轉換為VHD/VHDX 或 CIM 容器,以便能夠將其與 MSIX 應用程式附加一起使用,從而保持基礎映像輕量級,並根據使用者「附加」應用程式。

轉換環境的前提條件與準備

MSIX 封裝環境

為了成功轉換,必須從一個乾淨且可控制的環境開始。如果系統充斥著軟體和後台進程,工具可能會接收到干擾訊息,導致轉換結果不可靠。

使用 MSIX 打包工具的最低要求是:Windows 10 版本 1809 或更高版本,如果您要從應用程式商店安裝它,則需要一個 Microsoft 帳戶,如果您使用預覽體驗成員版本,則必須是 Windows 預覽體驗成員,並且在執行工具的電腦上擁有管理員權限。

建議專門使用一台機器(實體機、本機 Hyper-V 虛擬機器或遠端機器)進行鏡像擷取。此工具可讓您選擇在目前機器、遠端機器或本機 Hyper-V 虛擬機器上建立鏡像包。這樣可以更輕鬆地維護乾淨的鏡像,以便進行轉換。

在準備過程中,MSIX 打包工具會檢查並嘗試自動啟動所需的打包驅動程序,以便監控安裝過程。它還可以暫時暫停Windows 更新,並可選擇性地停止 Windows 搜尋或 SMS 主機等服務,以防止外部活動污染軟體套件。

如果系統有任何待重新啟動操作,該工具會通知您。雖然並非強制要求,但建議您在繼續擷取資料之前重新啟動系統,以避免操作中斷影響監控。

安裝並更新 MSIX 打包工具

取得工具最常見的方法是使用您的Microsoft 帳戶從 Microsoft Store下載。只需搜尋“MSIX Packaging Tool”,前往產品頁面,然後開始安裝即可。安裝完成後,它將自動更新到最新的穩定版本。

如果您喜歡自動化操作或從控制台操作,可以使用`winget install "MSIX Packaging Tool"` 命令進行安裝,這將大大簡化在託管環境或實驗室中的部署。

此外,還有一個專為無法存取應用程式商店的電腦設計的離線版本,其中包含應用程式套件及其許可證。在這種情況下,您可以使用PowerShell將套件新增至系統(例如,使用Add-AppxProvisionedPackage並指向 MSIX 檔案和 XML 授權)。

該工具會頻繁更新。最新版本顯著改進了與軟體包支援框架 (PSF) 的集成,從而允許在不修改程式碼的情況下,對那些無法很好地適應新容器模型的應用程式應用程式運行時進行修復。

選擇 MSIX 包類型並了解其變體

在使用 MSIX 時,我們並非只專注於“一個軟體包”,而是關注幾種用途各異的軟體包。了解這些差異有助於您規劃在各種場景下如何分發和安裝應用程式

  如何將 PS4 操縱桿連接到 PC。

基本格式是應用程式套件(.msix 或 .appx),其中包含應用程式及其針對特定架構(x86、x64、ARM、ARM64 等)的資源。如果需要支援多種架構,則需要為每種處理器類型建立一個軟體包。

其上方是應用程式套件(.msixbundle 或 .appxbundle),它將適用於不同架構的多個 MSIX 套件打包到一個檔案中。建議盡可能使用此選項,因為它簡化了部署,並允許系統僅為每個設備安裝必要的組件。

最後,要發佈到 Microsoft Store,需要使用上傳檔案(.msixupload 或 .appxupload),其中包含一個或多個程式包或捆綁包,以及用於故障排除的偵錯符號。當您打包打算上傳到 Microsoft Store 時,Visual Studio 會自動產生這些檔案。

從現有安裝程式建立 MSIX 套件

遷移舊版軟體的經典方法是使用 MSIX 打包工具作為嚮導,並按照引導流程操作,該流程會捕獲安裝程式執行的所有操作並將其轉換為 MSIX 格式。

啟動工具後,第一步是選擇任務類型。若要產生標準程式包,請選擇「建立應用程式套件」,然後決定是在本機電腦、遠端電腦或使用 Hyper-V 管理的本機虛擬機器上進行擷取。

完成系統準備工作(驅動程式、已停止的服務、已暫停的更新等)後,接下來需要指定要轉換的安裝程式。您可以選擇 MSI、EXE、App-V 5.x、ClickOnce 安裝程式、安裝腳本,或者如果您要執行完全手動安裝,您也可以將此欄位留空。

如果來源文件是MSI 文件,該工具可以讀取內部資料(產品名稱、版本、發布者等),並自動填入清單文件中的許多字段,從而節省時間並減少錯誤。此外,如果您有關聯的 MST 或 MSP 文件,則可以將其作為安裝程式參數傳遞。

對於App-V 5.x 版本,轉換過程通常更簡單,因為該版本已經包含豐富的清單檔案。在許多情況下,只需指定 App-V 檔案即可,工具會自動將資訊轉換為 MSIX 格式。注意:不支援 4.x 版本;對於 4.x 版本,建議使用原始安裝程式並直接進行轉換。

對於EXE 和 ClickOnce 安裝程序,其格式結構較為鬆散,工具無法提取足夠的元數據,因此您需要手動填寫大部分軟體包資訊(名稱、發布者、版本等)。 EXE 程式仍會在監控下執行,但配置監控的任務需要您自行完成。

如果您的安裝程序依賴自訂腳本(例如 PowerShell、CMD等),您可以在安裝精靈中指定命令列,也可以在安裝階段手動執行。此外,如果您想要完全控制安裝過程,您也可以選擇手動安裝,將安裝程式欄位留空,並在系統監控下手動執行每個步驟。

配置 MSIX 包簽名

關鍵一點:任何 MSIX 軟體包都必須使用目標系統認為可信任的憑證進行簽章才能安裝。因此,在安裝精靈過程中,您需要選擇簽署方式。

該工具支援多種選項。您可以使用Device Guard 簽名,這是一項基於 Azure AD 的 Microsoft 服務,專為不希望管理自身證書的企業環境而設計;或者,您可以使用自己的 .pfx 證書,這種證書在擁有內部 PKI 或公共機構證書的組織中很常見。

也可以選擇為軟體包指定一個未簽署的 .cer 文件,這有助於驗證清單發布者的信息是否與稍後將使用的證書相符。或者,您也可以在此階段保持軟體包未簽名,稍後使用您常用的工具對其進行簽名,但這會阻止安裝,直到簽名生效為止。

簽名時,強烈建議使用 RFC 3161 伺服器添加時間戳記。這樣即使證書過期,簽章仍然有效,這對於長期部署或審計至關重要。

填寫包裹資訊

選擇安裝程式和簽章原則後,您將進入定義MSIX 套件識別的畫面。許多欄位可能已預先填寫,但請務必仔細檢查,因為它們會影響程式的行為和使用者體驗。

軟體包名稱為必填項,區分大小寫,不包含空格,且必須與清單中的標識一致。最終用戶看不到此名稱,但它是系統使用的識別碼。軟體包名稱長度必須在 3 到 50 個字元之間,包含字母數字字元、連字符和句點,且不得以句點結尾,也不得與保留的系統名稱(例如 CON、PRN、COM1、LPT1 等)重複。

顯示名稱會顯示在「開始」功能表和「設定」頁面中。它可以翻譯,最多支援 256 個字符,並且應該具有描述性,以便用戶能夠輕鬆識別已安裝的應用程式。

關於發布者,有兩個值:技術名稱(Publisher),它必須與您用於簽署的證書主題完全匹配;以及顯示發布者名稱,用戶將在安裝對話方塊和應用程式商店中看到該名稱。前者是具有特定名稱格式(例如 CN=、O= 等)的字串,而後者則是更易於使用者理解的自由文字。

軟體套件版本採用四部分錶示法,格式為 Major.Minor.Build.Revision。此值對於更新至關重要,因為 Windows 會使用此編號來決定新軟體包是否取代舊軟體包。

您也可以指定選購的描述以及安裝程式複製應用程式檔案的安裝位置(通常為「Program Files」資料夾)。如果應用程式將元件安裝在「Program Files」資料夾之外,最好在此處進行指示,並在安裝過程中確保路徑匹配,以避免意外情況。

最後,還有一個複選框用於新增 MSIX Core 相容性,您可以在其中選擇要支援的最低 Windows 版本。 MSIX Core 可讓您在不完全原生支援的系統上安裝 MSIX 軟體包,從而略微擴展了可部署的機器範圍。

  允許在 Excel 和 Phrases 中選擇貨件收件者的方法

安裝和採集階段

定義完所有身分資訊後,精靈將進入監督安裝階段,在此階段,它會實際記錄安裝程式如何將其轉換為 MSIX 套件。

該工具會在您定義的環境中啟動安裝程式(或允許您手動執行)。之後,您應該像往常一樣按照應用程式的安裝精靈進行操作,但有幾點建議:使用一致的安裝路徑,建立指向您之前指定路徑的必要快捷方式,並停用任何內建的自動更新。

如果您的應用程式需要多個安裝程式、附加元件或諸如 .NET Framework 3.5 之類的先決條件,您可以利用此階段進行安裝,因為所有內容都會在螢幕截圖中顯示。如果您需要執行腳本或註冊其他 DLL,也適用相同的方法。

如果安裝程式需要重啟,該工具提供了一個受控重啟按鈕,以便系統重新啟動後從中斷的地方繼續轉換過程,而不會遺失正在監控的內容。

首次啟動管理和切入點

安裝的「可見」部分完成後,MSIX 打包工具會顯示擷取過程中偵測到的執行檔清單。您可以在此定義哪些捷徑會顯示為「開始」功能表中的應用程式項目,以及哪個是主捷徑。

建議至少從此畫面啟動一次主應用程序,以便記錄所有首次啟動任務(建立使用者資料夾、產生初始配置等),這些任務也將包含在軟體包中。

在同一視圖中,您可以移除不必要的入口點(輔助工具、卸載程式等),並選擇要作為主入口點的執行檔。如果主應用程式未出現在清單中,您可以手動在磁碟上找到它,運行它,然後更新偵測到的可執行檔清單。

點擊下一步後,工具會詢問您是否已完成這些初始啟動管理,或者是否需要返回完成任何其他配置、安裝更多檔案或啟動其他執行檔。

服務檢測和配置

在最新版本中,MSIX 打包工具包含一個專門用於服務報告的頁面。如果在安裝過程中建立了 Windows 服務,它們將顯示在兩個表格中:已包含(包含必要資訊)和已排除(資料缺失或服務與 MSIX 不相容)。

雙擊服務可以查看(在某些情況下還可以編輯)諸如描述、顯示名稱、啟動帳戶、啟動類型、啟動參數和依賴項等欄位。服務金鑰和可執行檔路徑無法透過此介面編輯。

調整完必要的設定後,您可以將服務從排除表移到包含表,使其成為最終 MSIX 套件的一部分;或者,如果您喜歡以其他方式管理該服務,您也可以將其保留在排除清單中。

建立、儲存和編輯 MSIX 包

完成上述所有定義後,精靈將進入套件建立步驟,您可以在此選擇要儲存產生的 MSIX 檔案的資料夾,以及(如果需要)轉換範本檔案的位置,以便您可以在其他電腦上以標準化的方式重複此過程。

預設情況下,程式包會保存在使用者的本機應用程式資料資料夾中,但您可以從工具的設定中變更目前路徑和預設位置,以適應您的工作流程。

在點擊「建立」之前,您可以選擇開啟套件編輯器,以便檢視和修改 MSIX 檔案的內容:包含的檔案、清單、功能、存取權限等。這對於進行一些小的調整非常有用,而無需重複整個捕獲過程。

創建過程完成後,該工具會顯示一個彈出窗口,其中包含指向已保存軟體包的資料夾的直接鏈接,以及指向轉換過程中生成的日誌文件的另一個鏈接(用於診斷問題或記錄過程)。

在其他機器上安裝和測試 MSIX 套件

在測試或生產機器上安裝 MSIX 軟體包非常簡單,只要係統信任用於簽署的憑證即可。在實驗室環境中,通常只需將憑證匯入到對應的憑證儲存區,然後雙擊 .msix 或 .msixbundle 檔案即可啟動Windows 應用程式安裝程式

對於已加入網域的計算機或具有更嚴格策略的計算機,通常的做法是透過GPO 或管理解決方案分發證書,以便所有計算機都能將頒發者識別為受信任的,並且可以安裝軟體包而不會出現簽名錯誤。

您也可以透過 PowerShell 安裝和解除安裝 MSIX,這對於自動化測試或受控部署非常有用。諸如Add-AppxPackageRemove-AppxPackage之類的命令可讓您以腳本化的方式管理程式包,而Get-AppxPackage則允許您查看已安裝應用程式的資訊。

安裝完成後,該應用程式不再作為經典程式出現在「程式和功能」中,而是作為 UWP 環境中的現代應用程式出現,通常位於C:\Program Files\WindowsApps,並具有相應的隔離和權限模型。

使用 Visual Studio 建立 MSIX 套件

如果應用程式正在開發中,並且您正在使用 Visual Studio,那麼最方便的方法是直接從專案中產生 MSIX,尤其是在 UWP 應用程式或封裝 Win32 應用程式的 Windows 應用程式打包專案中。

此過程的核心是Package.appxmanifest文件,這是一個 XML 文檔,用於描述程式包的標識、功能、圖示、螢幕方向、擴充聲明以及其他建置程式包所需的詳細資訊。 Visual Studio 提供了一個圖形化設計器,無需手動修改 XML 即可進行編輯。

在解決方案資源管理器中,請雙擊Package.appxmanifest即可開啟清單檔案。在不同的標籤中,您可以定義例如視覺資源(圖示、標誌、啟動畫面)或打包參數,包括用於簽署 MSIX 的憑證。

  在 Android 上離線使用 TikTok 的終極指南:您需要了解的一切,以確保您不會錯過自己喜歡的影片。

如果您要將項目發佈到 Microsoft Store,建議您使用「發布」→「將應用程式與商店關聯」選項,將您的項目與商店中的應用程式關聯起來。這樣會自動將某些打包欄位(識別、發布者等)與合作夥伴中心中的資訊同步。

配置好清單後,您可以從專案的「發佈」功能表啟動「建立應用程式包」精靈。在這裡,您可以選擇目標位置是側載(在應用程式商店之外分發)還是 Microsoft Store,要包含的架構,是否產生應用程式包,以及套件的簽署方式。

將文件上傳並提交至 Microsoft Store

如果您的目標是透過 Microsoft Store 分發應用程序,除了套件本身之外,您還需要一個上傳文件,即 .msixupload 或 .appxupload,該文件打包了程式包以及遙測和故障分析所需的符號。

如果您在精靈中選擇為 Microsoft Store 建立程式包的選項,Visual Studio 可以自動產生此檔案。在這種情況下,建立過程完成後,.msixupload 檔案將位於專案的輸出資料夾中,即可進行驗證並上傳至合作夥伴中心。

如果出於任何原因需要手動建立上傳文件,您可以將一個或多個.msix 包或 .msixbundle 包及其 .appxsym 符號文件組合到一個文件夾中,將它們壓縮成一個 ZIP 文件,然後將生成的文件的擴展名更改為 .msixupload 或 .appxupload。

在這些商店貼文中,如果您想利用合作夥伴中心提供的故障和效能分析功能,則包含公共符號非常重要;否則,偵錯資訊將受到限制。

使用 Windows 應用程式認證工具包進行驗證

在將任何軟體包上傳到應用程式商店之前(以及對於重要的內部部署),最好執行Windows 應用認證工具包 (WACK),該工具包會對軟體包執行一組自動化測試。

在 Visual Studio 精靈中,完成套件建立後,您可以直接在本機電腦或已安裝工具包的遠端裝置上執行 WACK。這些測試會檢查效能、API 使用情況、安全性和平台相容性等各個方面。

如果您有一台運行 Windows 10 的遠端設備,您可以將其啟用以進行開發,在其上安裝 Visual Studio 遠端工具和認證工具包,然後使用精靈中的「遠端電腦」選項從您的開發電腦針對該電腦執行測試。

一旦您的軟體包通過了 WACK 測試,您就可以將其提交給合作夥伴中心。產生的 .msixupload 檔案通常位於解決方案的 AppPackages 資料夾中,檔案名稱包含版本號和支援的架構。

從 Visual Studio 自動向 Microsoft Store 提交內容

在最新版本的 Visual Studio 中,可以更進一步,在軟體包通過 WACK 驗證後,直接從 IDE自動提交到 Microsoft Store 。

為此,您需要將合作夥伴中心帳戶與Azure Active Directory 租用戶關聯,並註冊具有管理員權限的 Azure AD 應用程序,以便向該帳戶提交內容。您可以從合作夥伴中心儀表板取得租戶 ID、客戶 ID 和金鑰。

在 Visual Studio 中設定好這些憑證後,在套件建立精靈結束時,您可以選擇在驗證後自動提交到應用程式商店的選項。此後,當 WACK 完成時,IDE 會自動啟動提交流程,您可以在「檢查並發佈」視窗中追蹤進度。

對於經常向應用程式商店交付產品並希望減少手動步驟,同時保持 Azure AD 在身份驗證方面提供的安全性的開發團隊來說,此工作流程尤其有用。

MSIX 應用附加和 VHD/CIM 容器

在桌面虛擬化場景(Windows 10/11 多用戶、Azure 虛擬桌面等)中,由於MSIX 應用附加技術允許應用程式與基礎映像解耦並從容器中加載,MSIX 變得更加有趣。

在這種模式下,應用程式不再安裝到作業系統映像中,而是轉換為VHD、VHDX 或 CIM 容器。這些容器在運行時掛載,系統將應用程式「附加」到使用者配置文件,從而減少鏡像大小並簡化版本管理。

CIM 檔案依賴複合映像檔系統 (CimFS),與傳統的 VHD 相比,CimFS 具有更快的掛載速度和更低的資源消耗。微軟提供了諸如 MSIX 管理器工具之類的工具,用於手動將 MSIX 檔案轉換為 VHD,而第三方實用程式(例如 MSIX Hero、AppVentiX 工具等)則簡化了轉換過程並將其整合到更大的工作流程中。

但是,要利用 MSIX 應用程式附加功能,必須滿足某些 Windows 版本要求(例如,Windows 10 2004 或更高版本),並且擁有有效的證書,允許系統信任將作為容器掛載的已簽署應用程式。

MSIX、打包工具、Visual Studio 和 app attach 共同構成了一個強大的生態系統,使您能夠實現部署現代化、減少應用程式衝突,並改善傳統環境和雲端環境中的管理。前提是您投入一些時間來了解每個組件,並制定符合您需求的打包策略。

啟用開發者模式在 Windows 11 上安裝未簽署的應用程式
相關文章:
在 Windows 11 中啟用開發人員模式並安全地測試未簽署的應用程式:包含風險、裝置入口網站、WSL 和驅動程式的完整指南