共用方式為

建立 ClickOnce 應用程式供其他人部署

  • 發行項

並非所有正在建立 ClickOnce 部署的開發人員都計畫自行部署應用程式。 他們當中的許多人只是使用 ClickOnce 封裝其應用程式，然後將檔案交給某位客戶，例如大型公司。 該客戶就會負責在其網路上裝載應用程式。 本主題討論在 3.5 版之前的 .NET Framework 版本中這類部署固有的問題。 接著會描述使用 .NET Framework 3.5 中新的「使用資訊清單提供信任」功能所提供的新解決方案。 最後會總結針對仍在使用舊版 .NET Framework 的客戶建立 ClickOnce 部署的建議策略。

為客戶建立部署所涉及的問題

當您計畫向客戶提供部署時，會發生幾個問題。 第一個問題涉及程式碼簽署。 若要跨網路部署，ClickOnce 部署的部署資訊清單和應用程式資訊清單都必須使用數位憑證簽署。 這會引發簽署資訊清單時，要使用開發人員的憑證還是客戶的憑證的問題。

使用哪一個憑證是很重要的問題，因為 ClickOnce 應用程式的身分識別是以部署資訊清單的數位簽章為基礎。 如果開發人員簽署部署資訊清單，而客戶是大型公司，且公司的多個部門部署自訂版本的應用程式，可能會導致衝突。

例如，假設 Adventure Works 有財務部門和人力資源部門。 這兩個部門都授權來自 Microsoft Corporation 的 ClickOnce 應用程式，從儲存在 SQL 資料庫中的資料產生報告。 Microsoft 會為每個部門提供針對其資料自訂的應用程式版本。 如果應用程式使用相同的 Authenticode 憑證簽署，則嘗試使用這兩個應用程式的使用者將會發生錯誤，因為 ClickOnce 會將第二個應用程式視為與第一個應用程式相同。 在此情況下，客戶可能會遇到無法預測和不必要的副作用，包括遺失應用程式在本機儲存的任何資料。

與程式碼簽署相關的其他問題是部署資訊清單中的 deploymentProvider 元素，它會告訴 ClickOnce 要在哪裡尋找應用程式更新。 在簽署之前，必須先將這個元素新增至部署資訊清單。 如果之後才新增這個元素，則必須重新簽署部署資訊清單。

要求客戶簽署部署資訊清單

這個非唯一部署問題的其中一個解決方案，是讓開發人員簽署應用程式資訊清單，客戶簽署部署資訊清單。 雖然此方法可行，但會引入其他問題。 由於 Authenticode 憑證必須保持為受保護的資產，因此客戶不能只是將憑證提供給開發人員簽署部署。 雖然客戶可以使用 .NET Framework SDK 免費提供的工具自行簽署部署資訊清單，但比起客戶願意或能夠提供，這可能需要更多的技術知識。 在這種情況下，開發人員通常會建立應用程式、網站或其他機制，讓客戶可以提交其應用程式版本以進行簽署。

客戶簽署對 ClickOnce 應用程式安全性的影響

即使開發人員和客戶都同意客戶應該簽署應用程式資訊清單，這也會引發應用程式身分識別的其他問題，特別是當應用在信任的應用程式部署時。 (如需此功能的詳細資訊，請參閱信任的應用程式部署概觀)。假設 Adventure Works 想要設定其用戶端電腦，讓 Microsoft Corporation 提供給它們的任何應用程式都以完全信任的方式執行。 如果 Adventure Works 簽署部署資訊清單，ClickOnce 會使用 Adventure Work 的安全性簽章來判斷應用程式的信任層級。

使用應用程式資訊清單提供信任來建立客戶部署

.NET Framework 3.5 中的 ClickOnce 包含一項新功能，為開發人員和客戶對於如何簽署資訊清單的案例提供一個新的解決方案。 ClickOnce 應用程式資訊清單支援一個名為 <useManifestForTrust> 的新元素，可讓開發人員表示應該使用應用程式資訊清單的數位簽章來做出信任決策。 開發人員使用 ClickOnce 封裝工具 (例如 Mage.exe、MageUI.exe 和 Visual Studio) 在應用程式資訊清單中包含這個元素，以及將發行者名稱和應用程式名稱內嵌在資訊清單中。

使用 <useManifestForTrust> 時，部署資訊清單不需要使用憑證授權單位所簽發的 Authenticode 憑證簽署。 但是可以使用所謂的自我簽署憑證進行簽署。 自我簽署憑證是由客戶或開發人員使用標準 .NET Framework SDK 工具所產生，然後使用標準 ClickOnce 部署工具套用至部署資訊清單。 如需詳細資訊，請參閱 MakeCert。

對部署資訊清單使用自我簽署憑證可提供數個優點。 客戶不需要取得或建立自己的 Authenticode 憑證，<useManifestForTrust> 可簡化客戶的部署，同時讓開發人員在應用程式維護自己的品牌身分識別。 結果是一組更安全且具有唯一應用程式身分識別的已簽署部署。 這可減少將相同應用程式部署到多個客戶時可能發生的潛在衝突。

如需如何建立已啟用 <useManifestForTrust> 的 ClickOnce 部署的逐步資訊，請參閱逐步解說：手動部署不需要重新簽署，並且保留商標資訊的 ClickOnce 應用程式。

應用程式資訊清單在執行階段提供信任的運作方式

若要更清楚了解如何在執行階段使用應用程式資訊清單提供信任，請參考下列範例。 某個以 .NET Framework 3.5 為目標的 ClickOnce 應用程式由 Microsoft 建立。 應用程式資訊清單使用 <useManifestForTrust> 元素，並由 Microsoft 簽署。 Adventure Works 使用自我簽署憑證簽署部署資訊清單。 Adventure Works 用戶端已設定為信任由 Microsoft 簽署的任何應用程式。

當使用者按一下部署資訊清單的連結時，ClickOnce 在使用者的電腦上安裝該應用程式。 憑證和部署資訊會唯一識別用戶端電腦上 ClickOnce 的應用程式。 如果使用者嘗試從不同位置再次安裝相同的應用程式，ClickOnce 可以使用此身分識別來判斷該應用程式已經在用戶端上。

接下來，ClickOnce 會檢查用來簽署應用程式資訊清單的 Authenticode 憑證，以判斷 ClickOnce 將授與的信任層級。 由於 Adventure Works 已將其用戶端設定為信任 Microsoft 所簽署的任何應用程式，所以此 ClickOnce 應用程式會獲得完全信任。 如需詳細資訊，請參閱信任的應用程式部署概觀。

建立舊版的客戶部署

如果開發人員將 ClickOnce 應用程式部署到使用舊版 .NET Framework 的客戶，該怎麼辦？ 下列各節摘要說明數個建議的解決方案，以及每個解決方案的優點和缺點。

代表客戶簽署部署

其中一個可能的部署策略是讓開發人員建立一種機制，使用客戶自己的私密金鑰，代表客戶簽署部署。 這可防止開發人員管理私密金鑰或多個部署套件。 開發人員只會為每個客戶提供相同的部署。 客戶可以自己決定，使用簽署服務來自訂其環境。

此方法的其中一個缺點是實作此方法需要花費時間和金錢。 雖然這類服務可以使用 .NET Framework SDK 中提供的工具來建置，但它會對產品生命週期增加更多開發時間。

如本主題稍早所述，另一個缺點是每個客戶的應用程式版本都會有相同的應用程式身分識別，這可能會導致衝突。 如果擔心，開發人員可以變更產生部署資訊清單時所使用的 [名稱] 欄位，讓每個應用程式都有唯一的名稱。 這會為每個應用程式版本建立個別的身分識別，就可以消除任何潛在的身分識別衝突。 此欄位對應至 Mage.exe 的 -Name 引數，以及 MageUI.exe 中 [名稱] 索引標籤上的 [名稱] 欄位。

例如，假設開發人員已建立一個名為 Application1 的應用程式。 開發人員可以使用此名稱的客戶特定變化建立數個部署，例如 Application1-CustomerA、Application1-CustomerB 等等，而不是將 [名稱] 欄位設定為 Application1 建立單一部署。

使用安裝封裝部署

第二個可能的部署策略是產生 Microsoft 安裝程式專案，以執行 ClickOnce 應用程式的初始部署。 這可透過數種不同格式的其中一種提供：以 MSI 部署、以安裝程式可執行檔 (.EXE)，或以封包檔 (.cab) 搭配批次指令碼。

開發人員會使用這項技術為客戶提供部署，其中包含應用程式檔案、應用程式資訊清單，以及做為範本的部署資訊清單。 客戶會執行安裝程式，程式會提示他們輸入部署 URL (使用者將安裝 ClickOnce 應用程式的伺服器或檔案共用位置)，以及數位憑證。 安裝應用程式也可以選擇提示輸入其他 ClickOnce 設定選項，例如更新檢查間隔。 收集此資訊之後，安裝程式會產生實際的部署資訊清單、簽署它，並將 ClickOnce 應用程式發佈至指定的伺服器位置。

在此情況下，客戶可以透過三種方式簽署部署資訊清單：

  1. 客戶可以使用憑證授權單位單位 (CA) 簽發的有效憑證。

  2. 另一種變化方法是，客戶可以選擇使用自我簽署憑證簽署其部署資訊清單。 缺點是，當使用者被問及是否要安裝時，會導致應用程式顯示「未知的發行者」這幾個字。 不過優點是，可以讓較小的客戶不必花費時間和金錢取得憑證授權單位所簽發的憑證。

  3. 最後，開發人員可以在安裝封裝中包含自己的自我簽署憑證。 這會引入本主題稍早討論的應用程式身分識別的潛在問題。

    安裝部署專案方法的缺點是，建置自訂部署應用程式需要花費時間和金錢。

讓客戶產生部署資訊清單

第三個可能的部署策略是，只將應用程式檔案和應用程式資訊清單交給客戶。 在此案例中，客戶負責使用 .NET Framework SDK 產生及簽署部署資訊清單。

此方法的缺點是，它要求客戶安裝 .NET Framework SDK 工具，而且要有能夠使用這些工具的開發人員或系統管理員。 有些客戶可能需要一個技術性很低的解決方案。

相關內容