並非所有建立 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 為基礎的多個部署，為不同客戶指定名稱，例如 Application1-CustomerA、Application1-CustomerB 等，而不是創建只設為 Application1 的單一部署。
使用安裝套件進行部署
第二個可能的部署策略是產生 Microsoft 安裝程式專案，以執行 ClickOnce 應用程式的初始部署。 這可以提供多種不同的格式，例如 MSI 部署、安裝執行檔（.EXE）或機櫃檔案（.cab），以及附帶的批次腳本。
使用此技術，開發人員會為客戶提供包含應用程式檔案、應用程式資訊清單和做為範本的部署資訊清單的部署。 客戶會執行安裝程式，這會提示他們輸入部署 URL （使用者將從中安裝 ClickOnce 應用程式的伺服器或檔案共用位置） ，以及數位憑證。 安裝應用程式也可以選擇提示輸入其他 ClickOnce 組態選項，例如更新檢查間隔。 收集此資訊之後，安裝程式會產生實際的部署資訊清單、簽署它，並將 ClickOnce 應用程式發佈至指定的伺服器位置。
在此情況下，客戶可以透過三種方式簽署部署資訊清單：
客戶可以使用憑證授權單位 （CA） 所核發的有效憑證。
作為此方法的變體，客戶可以選擇使用自我簽署憑證簽署其部署資訊清單。 這樣做的缺點是，當詢問用戶是否安裝它時，它會導致應用程序顯示“未知發布者”一詞。 然而，好處是它可以防止較小的客戶花費獲取認證機構頒發的憑證所需的時間和金錢。
最後，開發人員可以在安裝套件中包含自己的自簽名證書。 這引進了本主題稍早討論的應用程式身分識別的潛在問題。
設定部署專案方法的缺點是建置自訂部署應用程式所需的時間和費用。
讓客戶產生部署資訊清單
第三種可能的部署策略是只將應用程式檔案和應用程式資訊清單移交給客戶。 在此案例中，客戶負責使用 .NET Framework SDK 來產生和簽署部署資訊清單。
此方法的缺點是它需要客戶安裝 .NET Framework SDK 工具，並擁有擅長使用這些工具的開發人員或系統管理員。 一些客戶可能需要一種幾乎不需要或完全不需要技術上投入的解決方案。