共用方式為

準備封裝傳統型應用程式

  • 發行項

本文列出封裝傳統型應用程式之前，您需要知道的事項。 您可能不需要針對應用程式的封裝程序做太多準備，但如果以下任何項目適用於應用程式，就需要先處理之後才能封裝。

  • 您的 .NET 應用程式需要 4.6.2 之前的 .NET Framework 版本。 如果您要封裝 .NET 應用程式，我們建議應用程式將 .NET Framework 4.6.2 或更新版本設為目標。 能夠安裝和執行已封裝傳統型應用程式的能力，最先是在 Windows 10 版本 1607 (也稱為年度更新版) 中引進，而此 OS 版本預設會包含 .NET Framework 4.6.2。 更新的作業系統版本包含更新版本的 .NET Framework。 如需更新 Windows 10 版本中包含哪些 .NET 版本的完整清單，請參閱這篇文章。

    在封裝的傳統型應用程式中，將 4.6.2 之前的 .NET Framework 版本設為目標，預期可在大部分情況下運作。 不過，如果您將 4.6.2 之前的版本設為目標，應該先完整測試封裝的傳統型應用程式，然後再將其散發給使用者。

    • 4.0 - 4.6.1：以這些 .NET Framework 版本為目標的應用程式預期會在 4.6.2 或更新版本上執行，而不會發生問題。 因此，無需變更，這些應用程式即可在 Windows 10 版本 1607 版或更新版本，以及作業系統隨附的 .NET Framework 版本上安裝及執行。

    • 2.0 和 3.5：在我們的測試中，以這些 .NET Framework 版本為目標的封裝傳統型應用程式通常會運作，但在某些情況下可能會顯示效能問題。 為了讓這些封裝的應用程式能夠安裝和執行，必須在目標電腦上安裝 .NET Framework 3.5 功能 (此功能也包含 .NET Framework 2.0 和 3.0)。 您也應該在封裝這些應用程式之後徹底測試。

  • 您的應用程式一律會以提升的安全性權限執行。 在以互動使用者身分執行時，您的應用程式必須能夠運作。 安裝應用程式的使用者可能不是系統管理員，因此需要以提升的權限來執行應用程式，表示其無法針對標準使用者正常執行。 如果您打算將應用程式發佈到 Microsoft Store，Mcirosoft Store 將不會接受其功能任何部分需要提升權限的應用程式。

  • 您的應用程式需要 Windows 驅動程式。 MSIX 不支援 Windows 驅動程式。

  • 您的應用程式需要使用者 Windows 服務。 MSIX 不支援每個使用者的 Windows 服務。 MSIX 支援在其中一個定義的系統帳戶 （LocalSystem、LocalService 或 NetworkService） 下執行的會話 0 （每部計算機） 服務。 使用背景工作，而不是使用者 Windows 服務。

  • 您的應用程式模組會以同處理序載入至不在 Windows 應用程式套件中的處程序。 不允許這樣做，這表示不支援進程內延伸模組，例如 殼層延伸模組。 但是，如果您在相同的套件中有兩個應用程式，您可以在它們之間進行進程間通訊。

  • 確定應用程式所安裝的任何擴充功能都會安裝在應用程式的安裝位置上。 Windows 可讓使用者和 IT 管理員變更套件的預設安裝位置。 請參閱「設定-System->>儲存體->更多 儲存體 設定- 變更儲存新內容的位置 ->> 新應用程式將儲存至 」。 如果您要使用應用程式安裝擴充功能，請確定延伸模組沒有額外的安裝資料夾限制。 例如，某些擴充功能可能會停用將其擴充功能安裝到非系統磁碟機的功能。 如果預設位置已變更，這會導致錯誤 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY)。

  • 您的應用程式會使用自訂的應用程式使用者模型識別碼 (AUMID)。 如果您的處理序會呼叫 SetCurrentProcessExplicitAppUserModelID 來設定自己的 AUMID，則其可能只會使用應用程式模型環境/Windows 應用程式套件為其產生的 AUMID。 您無法定義自訂 AUMID。

  • 您的應用程式會修改 HKEY_LOCAL_MACHINE (HKLM) 登錄區。 應用程式對於建立 HKLM 機碼，或開啟某一個機碼進行修改的任何嘗試，都將造成存取遭拒失敗。 請記住，您的應用程式有自己的登錄私人虛擬化檢視，因此，使用者和全計算機登錄區的概念（也就是 HKLM 是什麼）不適用。 您將需要找到另一種方法，以達到您使用 HKLM 的方式，例如改為寫入HKEY_CURRENT_USER（HKCU）。

  • 您的應用程式會使用 ddeexec 登錄子機碼做為啟動另一個應用程式的方式。 請改用其中一個 DelegateExecute 動詞處理程式，如應用程式 套件指令清單中的各種可啟動* 擴充功能所設定。

  • 您的應用程式會寫入 AppData 資料夾或登錄，以便與其他應用程式共用資料。 轉換之後，系統會將 AppData 重新導向至本機 app 資料存放區，此為每一個應用程式的私人存放區。

    您的應用程式寫入至 HKEY_LOCAL_MACHINE 登錄區的所有項目都會重新導向至隔離的二進位檔，而應用程式寫入至 HKEY_CURRENT_USER 登錄區的任何項目都會放到私人的各個使用者、各個應用程式位置。 如需檔案和登錄重新導向的詳細資訊，請參閱傳統型橋接器的幕後作業。

    使用不同的方式進行進程間數據共用。 如需詳細資訊，請參閱 儲存和擷取設定和其他應用程式數據。

  • 您的應用程式會寫入應用程式的安裝目錄。 例如，您的應用程式所寫入的記錄檔是放在與 exe 相同的目錄中。 不支援此功能，因此您必須尋找另一個位置，例如本機應用程式資料存放區。

  • 您的應用程式會使用目前的工作目錄。 在執行階段，已封裝的傳統型應用程式將不會取得您先前在桌面 .LNK 捷徑中指定的相同工作目錄。 如果您的應用程式必須擁有正確的目錄才能正確運作，則需要在執行階段變更 CWD。

    注意

    如果您的應用程式需要寫入安裝目錄，或使用目前的工作目錄，您也可以考慮使用套件支援架構，將執行階段修復新增至套件。 如需詳細資料，請參閱這篇文章。

  • 您的應用程式安裝需要使用者互動。 您的應用程式安裝程式必須能夠以無訊息方式執行，而且其需要安裝所有預設不在全新作業系統映像上的必要條件。

  • 您的應用程式會公開 COM 物件。 來自套件內的處理序和擴充功能可以正常登錄及使用 COM 物件及 OLE 伺服器，並且在處理序內和處理序外 (OOP) 皆可以。 Creators Updates 新增了封裝 COM 的支援，提供了現在可在套件外部看見 OOP COM 及 OLE 伺服器的登錄能力。 請參閱適用於傳統型橋接器的 COM 伺服器和 OLE 文件支援。

    封裝 COM 支援與現有的 COM API 相容，但無法用於依賴直接讀取登錄檔的應用程式擴充功能，因為封裝 COM 是位於一處私人位置。

  • 您的應用程式公開 GAC 組件給其他處理序使用。 您的應用程式不能公開 GAC 組件給來自 Windows 應用程式套件外部的可執行檔處理序使用。 來自套件內的處理序可以正常登錄及使用 GAC 組件，但無法從外部看見。 這表示如果外部進程叫用，OLE 之類的 Interop 案例將無法運作。

  • 您的應用程式以不支援的方式連結 C 執行階段程式庫 (CRT)。 Microsoft C/C++ 執行時間連結庫提供 Microsoft Windows 作業系統程式設計例程。 這些常式會自動執行 C 和 C++ 語言所未提供的許多常見的程式設計工作。 如果您的應用程式利用 C/C++ 執行階段程式庫，則您必須確定以支援的方式連結。

    Visual Studio 2017 支援同時用靜態和動態連結 (讓程式碼使用一般 DLL 檔案) 或用靜態連結 (將程式庫直接連結到程式碼中)，連結到目前的 CRT 版本。 可以的話，我們建議您的應用程式搭配 VS 2017 使用動態連結。

    舊版Visual Studio的支援會有所不同。 如需詳細資訊，請參閱下表：

    Visual Studio 版本動態連結靜態連結
    2005 年 （VC 8）不支援支援
    2008 年 （VC 9）不支援支援
    2010 年 （VC 10）支援支援
    2012 年 （VC 11）支援不支援
    2013 年 （VC 12）支援不支援
    2015 和 2017 (VC 14)支援支援

    注意：在所有情況下，您必須連結至最新的公開 CRT。

  • 您的應用程式會從 Windows 並列資料夾安裝與載入組件。 例如，您的應用程式使用 C 執行階段程式庫 VC8 或 VC9 且從 Windows 並列資料夾動態連結，表示您的程式碼是使用來自共用資料夾的通用 DLL 檔。 不支援此連結方式。 您必須將可轉散發連結庫檔案直接連結到您的程式代碼，以靜態方式連結它們。

  • 您的應用程式使用 System32/SysWOW64 資料夾中的相依性。 若要讓這些 DLL 能夠運作，您必須將其包含於 Windows 應用程式套件的虛擬檔案系統部分。 這可確保應用程式行為就如同已將 DLL 安裝在 System32/SysWOW64 資料夾中。 在套件的根目錄中，建立名為 VFS 的資料夾。 在該資料夾內建立 SystemX64 和 SystemX86 資料夾。 然後，將 DLL 的 32 位版本放在 SystemX86 資料夾中，並將 64 位版本 放在 SystemX64 資料夾中。

  • 您的應用程式使用 VCLibs 架構套件。 如果您要轉換 C++ Win32 應用程式，則必須處理 Visual C++ Runtime 的部署。 Visual Studio 2019 和 Windows SDK 包含下列資料夾中 Visual C++ Runtime 11.0、12.0 和 14.0 版的最新架構套件：

    • VC 14.0 架構套件：C：\Program Files （x86）\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

    • VC 12.0 架構套件：C：\Program Files （x86）\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

    • VC 11.0 架構套件：C：\Program Files （x86）\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

    若要使用其中一個套件，您必須在封裝資訊清單中將套件當做相依性來參考。 當客戶從 Microsoft Store 安裝零售版應用程式時，會從 Microsoft Store 安裝套件以及應用程式。 如果您要載入應用程式，將不會安裝相依性。 若要手動安裝相依性，您必須使用位於上述安裝資料夾中適當的 x86、x64 或 ARM .appx 套件來安裝適當的架構套件。

    若要在您的應用程式中參考 Visual ++ Runtime 架構套件：

    1. 移至上面所列的架構套件安裝資料夾，找出您應用程式使用的 Visual C++ Runtime 版本。

    2. 開啟該資料夾中的 SDKManifest.xml、找出 FrameworkIdentity-Debug 或 FrameworkIdentity-Retail 屬性 (視您使用的是執行階段的偵錯版本還是零售版本而定)，然後從該屬性複製 Name 和 MinVersion 值。 例如，以下是目前 VC 14.0 架構套件的 FrameworkIdentity-Retail 屬性。

      FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"

    3. 在您應用程式的封裝資訊清單中，於 <Dependencies> 節點下新增下列 <PackageDependency> 元素。 務必將 Name 和 MinVersion 值取代為您在上一個步驟中複製的值。 下列範例會指定 VC 14.0 架構套件目前版本的相依性。

      <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

  • 您的應用程式包含自訂捷徑清單。 使用捷徑清單時有幾個問題和注意事項。

    • 您的應用程式架構不符合 OS。 捷徑清單目前無法正常運作，如果應用程式和作業系統架構不相符 (例如 x86 應用程式在 x64 Windows 上執行)。 目前還沒有其他因應措施，除了重新編譯應用程式以符合架構之外。

    • 您的應用程式會建立捷徑清單項目，並呼叫 ICustomDestinationList::SetAppID 或 SetCurrentProcessExplicitAppUserModelID。 請勿以程序設計方式在程式碼中設定AppID。 這麼做會導致跳躍清單專案未出現。 如果您的應用程式需要自訂識別碼，請使用資訊清單檔案加以指定。 如需指示，請參閱手動封裝傳統型應用程式。 應用程式的 AppID 是在 [YOUR_PRAID_HERE] 區段中指定。

    • 應用程式會新增參考套件中可執行檔的捷徑清單 Shell 連結。 您無法從快捷方式清單直接啟動套件中的可執行檔（但應用程式本身 .exe的絕對路徑除外）。 請改為註冊應用程式執行別名 (可讓您的已封裝傳統型應用程式透過關鍵字啟動，就形同其在 PATH 上)，並改為設定別名的連結目標路徑。 如需有關如何使用 appExecutionAlias 擴充功能的詳細資料，請參閱整合您的傳統型應用程式與 Windows 10。 請注意，如果您需要跳躍清單中的鏈接資產以符合原始的 .exe，則必須使用 SetIconLocation 設定圖示之類的資產，並使用PKEY_Title顯示名稱，就像您針對其他自定義專案一樣。

    • 您的應用程式會新增可依絕對路徑參考應用程式套件中資產的捷徑清單項目。 更新應用程式套件時，應用程式的安裝路徑可能會變更，也會變更資產位置 (例如圖示、文件、可執行檔等)。 如果捷徑清單項目依絕對路徑參考這類資產，則應用程式應該定期重新整理其捷徑清單 (例如應用程式啟動時)，確保路徑解析正確。 或者，請改用UWP Windows.UI.StartScreen.JumpList API，這可讓您使用套件相對 ms-resource URI 配置來參考字元串和影像資產（亦即語言、DPI 和高對比度感知）。

  • 您的應用程式會啟動公用程式以執行工作。 避免啟動命令公用程式，例如 PowerShell 和 Cmd.exe。 事實上，若使用者將您的應用程式安裝至執行 Windows 10 S 的系統上，那麼應用程式將會完全無法啟動。 這可能會使得您的應用程式無法提交至 Microsoft Store，因為提交到 Microsoft Store 的所有應用程式都必須與 Windows 10 S 相容。

    啟動公用程式通常可以提供一個便利的方式來取得作業系統資訊、存取登錄，或存取系統功能。 然而，您也可以改用 UWP API 來完成這類工作。 這些 API 的效能是最好的，因為不需要個別的可執行檔即可執行，但重要的是，會禁止應用程式觸達套件的外部。 應用程式的設計與您所封裝應用程式隨附的隔離、信任和安全性維持一致，而且應用程式在執行 Windows 10 S 的系統上也會如預期般運作。

  • 您的應用程式裝載增益集、外掛程式或擴充功能。 很多時候，只要擴充功能尚未封裝，且其本身是以完全信任的模式安裝的，COM 式的擴充功能都會繼續運作。 這是因為那些安裝程式可以使用其完全信任的功能修改登錄，並將擴充功能檔案放在您主機應用程式能找到的任何地方。

    然而，若那些擴充功能已封裝，且以 Windows 應用程式套件的方式安裝，其將會無法正常運作，因為每一個套件 (主機應用程式及擴充功能) 都是互相隔離的。 若要深入了解如何從系統中隔離應用程式，請參閱傳統型橋接器的幕後作業。

    使用者安裝到執行 Windows 10 S 之系統的所有應用程式和擴充功能，都必須安裝為 Windows 應用程式套件。 因此，若您想要封裝擴充功能，或想要鼓勵參與者們進行封裝，建議您考慮如何協助主機應用程式套件和任何擴充功能套件之間的通訊。 要達到這個目的的其中一個可能的方式，就是使用應用程式服務。

  • 您的應用程式會產生程式碼。 您的應用程式可以在記憶體中產生它取用的程式代碼，但避免將產生的程式代碼寫入磁碟，因為 Windows 應用程式認證程式無法在應用程式提交之前驗證該程式代碼。 同時，將程式碼寫入磁碟的應用程式將不會在執行 Windows 10 S 的系統上正常運作。這可能會使得您的應用程式無法提交至 Microsoft Store，因為提交到 Microsoft Store 的所有應用程式都必須與 Windows 10 S 相容。

重要

建立 Windows 應用程式套件之後，請測試您的應用程式以確定其可在執行 Windows 10 S 的系統上正確運作。提交到 Microsoft Store 的所有應用程式都必須與 Windows 10 S 相容。Microsoft Store 不接受不相容的應用程式。 請參閱針對 Windows 10 S 測試您的 Windows 應用程式。