實現.NET應用程序的自動更新

　　應用程序更新的方法一般有兩種：一是通知用戶（比如發E-mail）,讓用戶到指定的網站地址下載更新的程序；二是將更新的職責從用戶那邊轉移到應用程序自身，由應用程序自身取代用戶獲取并安裝一個軟件的更新，客戶端應用程序自身負責從一個已知服務器下載并安裝更新，用戶唯一需要進行干預的是決定是否愿意現在或以后安裝新的更新。顯然，后者比前者更友好。你現在可以看到類似后一種方法的實際產品，比如Windows XP和Microsoft Money。本文所介紹的.NET應用程序更新組件就可以提供類似的功能。

　　一、.NET應用程序更新組件介紹

　　.NET 應用程序更新組件AppUpdater 是使用.NET框架開發的。盡管AppUpdater 不是微軟的產品，但是只要你在VS.NET工具欄中添加了該組件，就可以象使用其它組件一樣通過拖拽的方式將該組件從工具欄中拖放到你的應用程序中，并設置一些屬性（比如獲取更新的位置、頻率等）之后就可以使得你的客戶端應用程序具備自動更新的功能。

　　二、工作原理

　　要深入理解.NET客戶端應用程序更新組件的工作原理，需要仔細研究一下實現客戶端應用程序更新有那些必須要做的事情。第一步需要做的是檢查是否有更新；當發現有更新時，開始第二步工作——下載更新；當更新下載完成時，進行是最后一步的工作——實現更新。

　　(一) 為更新做檢查

　　作為開發者，首先你得告訴應用程序到什么地方去做更新檢查，否則它豈不是要大海撈針？其次，確定何時做更新檢查。不可能用戶每次一運行客戶端程序，而它就在后臺不停的進行更新檢查，那多浪費資源！最后還有一項重要的事情需要解決，那就是如何進行更新檢查。.NET應用程序更新組件使用HTTP進行通訊，這就允許客戶端應用程序穿透防火墻來進行更新。并且進行更新檢查所需要的地址就成了已知的Web服務器的一個URL地址，第一個問題順利解決。

　　.NET應用程序更新組件在組件生成的基礎上產生一個線程，該線程負責進行更新檢查。該線程在大多數時間處于休眠狀態，但會在設置好的間隔蘇醒并實現一次更新檢查。應用程序為新的更新所做的檢查的頻率依賴于各應用自身。進行更新檢查的間隔常用值的范圍一般是從一個小時到幾天。這種輪詢的基本方法并不適合于所有情況。比如Microsoft Money只是在用戶讓它去進行更新檢查時它才去檢查。在這種情況下，更新輪詢線程可被禁用。

　　通過用命令調用更新組件的CheckForUpdate()方法來實現更新檢查。

　　關于如何進行更新檢查的方法有這樣幾種：

　　方法一：直接文件檢查——使用HTTP來比較服務器和客戶端應用程序的最后的修改日期/時間戳是否一致。如果服務器上有更新的文件，客戶端就知道可以更新自己了。對于Web瀏覽器來講，也是同樣的道理，它知道是否需要重新下載一個html頁面或圖片或是否可以
重復使用先前已下載的。當應用程序有一個新的版本可用時，管理員簡單地拷貝一個更新的版本來覆蓋Web服務器上的舊版本。這種方法的問題在于更新不是自動進行，由此會出現潛在的失敗可能。比如，如果管理員正在更新Web服務器上的應用程序版本，同時有個客戶正在下載更新之前的版本，那么這個客戶的計算機上就會既存在更新之前的一些文件，也存在更新之后新版本的一些文件?；谏鲜鲈?，對于重要的應用程序不提倡使用直接文件檢查來更新。

　　方法二：顯式檢查——在服務器上使用一個顯式的配置文件。一個可和.NET應用程序更新組件使用的有效服務器顯式文件大致是這個樣子：..

clearcase/" target="_blank" >cccccc width="90%" align=center bgColor=#e3e3e3 border=1>

＜VersionConfig＞ ＜AvailableVersion＞1.0.0.0＜/AvailableVersion＞ ＜ApplicationUrl＞http://localhost/demos/selfupdate/V1/＜/ ApplicationUrl＞ ＜/VersionConfig＞

　　AvailableVersion指定最新的可用程序集的版本號。ApplicationURL屬性指定該版本應用程序所在的URL地址。當管理員想要更新客戶端應用程序時，他們就會將應用程序的新版本拷貝到Web服務器上并且適當地修改服務器顯式文件?？蛻舳俗陨頃綔y到服務器顯式文件已被修改，然后下載顯式文件?？蛻舳穗S后比較顯式文件中指定的程序集版本號與應用程序EXE文件的版本號。如果服務器顯式文件中的可用版本號較新，應用程序就知道需要更新了。這種方法對大多數應用程序而言是推薦使用的方法。

　　方法三：XML Web Service 檢查——XML WebServices提供一種更高級的更新檢查方式。比如，假定你希望在進行更新你的其他用戶之前先對一系列早期用戶進行更新，如果客戶端應用程序調用一個XML WebService來檢查一項更新是否可用，那個XML Web Service還可以在數據庫中查詢該用戶并判斷該用戶是否是早期用戶。如果他們是早期用戶，XML Web Service就返回一個值表示更新可用。如果不是，Web Service就返回一個值表示更新不可用。但本文介紹的.NET應用程序更新組件并不提供直接的XML Web Service支持。

　　要采用XML Web Service來進行更新檢查，首先建立 XML Web Service并掛鉤一個OnCheckForUpdate事件。這樣就允許你自己的自定義檢查代替輪詢者線程更新檢查。OnCheckForUpdate事件有一個返回值，該值表示更新是否被檢測到。

　　(二) 下載更新

　　當.NET應用程序更新組件檢測到一項新的更新可用時它會自動啟動另一個線程并開始異步后臺下載更新。

　　下載使用HTTP-DAV來完成。DAV 是一種擴展的HTTP，.. 它提供諸如目錄和文件枚舉這樣的功能。一項完整的下載過程始于指定一個URL。采用URL來下載依賴于完成更新檢查所使用的方式。比如，如果使用服務器顯式文件，下載更新所用的URL通過在服務器顯式文件 中的ApplicationURL屬性指定。

　　更新下載顯然需要一定的健壯性。在下載和更新之后讓客戶端應用程序處于任何不穩定的狀態是不可接受的。下載過程中任何問題可能都會出現：更新文件所屬的Web 服務器可能會宕機，客戶端機器可能會崩潰，或者因為某種原因用戶只是簡單的關閉了應用程序。由于
應用程序正在進行下載，如果它被關閉的話，下載將會停止。一種可選的設計方案是使用單獨的系統服務來進行應用程序的下載和更新。使用系統服務，即便應用程序自身沒有在運行，更新下載也會繼續。實際上，Windows XP就有一種稱之為BITS的內建的下載服務，其目的即在此。BITS是Windows XP用來對Windows自身進行下載更新的。想查看更多關于BITS的信息，請參閱http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp。在.NET應用程序更新組件中沒有使用這種服務，因此它可以在不支持系統服務的Windows 9x中使用。

　　(三) 實現更新

　　.NET應用程序更新組件通過將下載和更新過程分為單獨的兩個階段來獲得健壯性。當每一階段都完成時，在位于客戶端應用程序目錄下的一個更新顯式文件（manifest file）中記載下來。如果下載或更新任何一個階段中的過程被打斷，它就會在下一次應用程序啟動時從上一次完成的斷點繼續原來的工作。每一階段都可以重新運行，因此如果在一個階段中間出現失敗，重新運行該階段就可以成功。如果有錯誤發生，比如在下載過程中與服務器的鏈接丟失，.NET更新組件將會在稍后重試。如果報告了非常多的錯誤（例如web服務器再也沒有回到在線狀態），下載和更新將會被放棄并且報告出錯誤。

　　我們的第一個方法是簡單地啟動一個單獨的進程來實現更新。這個單獨的進程將會首先關閉應用程序進程，實現更新（因為這時候已被解鎖），重啟應用程序進程并且在完成之后關閉自己。因此，這種設計存在三個基本的問題：

　　. 在某些情況下它不起作用。在更新應用程序時，更新進程關閉原始的應用程序進程，更新進程自身也要被關閉，因此也就不會實現更新。

　　. 我們希望能夠自動更新所有要實現更新的代碼。我們希望自動安裝修補的能力不僅僅發生在應用程序上，而且.NET應用程序更新組件自身也可以。使用這種模式，我們不能更新實現更新的進程。

　　. 強制用戶關閉應用程序并在使用過程中等待，這是很不禮貌的。

　　用來實現應用程序更新的最后一種方法是使用.NET框架并行程序集模式。作為試圖更新應用程序自身的替代方案，生成一個比目前存在版本新的應用程序版本。

　　新版本可以通過合并目前現存的應用程序目錄與下載的更新版本來生成。當新版本完成時，用戶在下次重新打開應用程序時會自動使用新版本。原始應用程序的拷貝就可以被移除了。棘手問題是弄清在某個指定時刻哪個版本該被載入。我們介紹一個名稱為Appstart的應用程
序。Appstart是進入你應用程序的入口點，使用這種模式，你的應用程序目錄看起來是這個樣子：..

--＞ Program Files

--＞ MyApp

--＞ Appstart.exe

--＞ Appstart.config

--＞ V1 Folder

--＞ MyApp.exe

--＞ V1.1 Folder

--＞ MyApp.exe

　　要運行你的應用程序，你通常是啟動Appstart.exe。如果你想在桌面上有個快捷鍵，那個快捷鍵必須應該指向Appstart而不是直接指向應用程序（注意，你可以重命名AppStart.exe 為任何你想要的名字，例如YourApp.exe）Appstart.exe是個非常簡單的程序，它讀取Appstart.config文件并且載入指定的應用程序。一個有效Appstart.config文件如下所示：

＜Config＞ ?。糀ppFolderName＞V1 Folder＜/AppFolderName＞ ?。糀ppExeName＞MyApp.exe＜/AppExeName＞ ?。糀ppLaunchMode＞appdomain＜/AppLaunchMode＞ ＜/Config＞

　　AppFolderName指定包含當前要運行的應用程序版本的子文件夾。AppExeName包含在那個文件夾下要載入的exe文件名。當一個應用程序更新完成時，最后一步就是修改AppFolderName的值為指向應用程序的新版本。這樣，下次用戶運行應用程序時，就會運行新的應用程序更新后的版本。AppLaunchMode指定如何加載應用程序。有兩種方式加載應用程序：第一種方式是使用AppDomains。AppDomains是.NET框架公
用語言運行時的特性，也是獨立的邏輯單元和管理對象。公用語言運行時允許每個進程中存在多個應用程序域。這樣Appstart.exe就能夠在單獨的AppDomain中同時卻是相同的AppStart.exe進程中加載你的應用程序。盡管事實是兩個不同的exe 程序在運行（即Appstart.exe和MyApp.exe），但只有一個進程在使用。對于大多數應用程序AppDomains會工作得很好，當然，在一個單獨的AppDomain中運行和在一個單獨
的進程中運行還是有些細微區別的。在這種情況下，AppLaunchMode可以設置為“process”，這樣就會使應用程序在單獨進程中加載。

　　一旦Appstart啟動應用程序，它就會進入休眠狀態等待應用程序終止。一旦應用程序終止，Appstart也會關閉。

　　三、實例演練

　　前面我們討論了.NET應用程序更新是如何工作的，現在我們來將它應用在實例中。

　　第一步：建立應用程序來進行更新

　　1. 使用VS.NET生成一個新的Windows應用項目，命名為"SampleApp"。

　　2. 給窗體一個你選擇的有趣的背景色。我們將使用背景色來與后面更新的版本區別。

　　3. 現在讓我們給這個應用程序增加一個細微的功能，首先給你的窗體增加一個按鈕。壓縮文件中包含一個擁有簡單Windows窗體的程序集。給壓縮文件中 Samples\SampleApp\SimpleForm 程序集增加一個引用。然后在你的按鈕事件句柄中添加兩行代碼：

..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.Show();

　　4. 將你的build標志從debug轉換為RELEASE。這將允許我們避免稍后當我們生成一個應用程序的新版本而同時原始拷貝正在運行產生的pdb文件鎖定問題。生成并測試你的應用程序。

　　第二步：添加.NET應用程序更新組件

　　1. 在VS.NET工具欄的組件標簽上，右擊選擇“自定義工具欄”。選擇“.NET框架組件”標簽。點“瀏覽”并選擇位于壓縮文件中AppUpdater 項目下的AppUpdater.dll，單擊OK。

　　2. 一個AppUpdater圖標現在應該出現在工具欄的組件列表的底部。將AppUpdater 組件拖放到SampleApp窗體上。一個名為appUpdater1的.NET應用程序更新組件的實例會出現在窗體的底部。

　　第三步：設置.NET應用程序更新組件

　　在這一步我們將設置.NET應用程序更新組件。注意這個示例你只需改變最開始的四個屬性，其它的采用默認值。

　　AppUpdater屬性：這是.NET Application應用程序更新的核心，對于本程序需要做以下設置：

　?。?)AutoFileLoad：這個控制后面要描述的命令下載特征，現在將它設置為true。

　?。?）ChangeDetectionMode：該枚舉決定如何為更新進行檢查。在該例中，我們將使用一個服務器顯式檢查，因此將這個值設置為“ServerManifestCheck ”。

　?。?）ShowDefaultUI： .NET 應用程序更新組件具有一系列用戶界面來通知用戶一些事件，比如有一個新的更新可以使用了或者在更新期間發生錯誤等。這種用戶界面可以通過設置默認的用戶界面為無效而用自定義應用程序指定的用戶界面來代替它，掛鉤適當的事件（比如
OnUpdateComplete）并彈出自定義用戶界面。對于該例我們將使用默認的用戶界面，因此將這個值設置為true 。

　?。?）UpdateUrl ：UpdateUrl 是決定更新程序到何處去尋找更新的。在該例中我們使用一個服務器顯式文件來檢查更新，因此這個屬性應當設置為服務器顯式文件的URL 。

　　在該例中將它設置為：http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml。請用你的Web 服務器名
稱來代替“yourWebserver ”。

　　Downloader 屬性:AppUpdater 組件有兩個子組件。第一個稱之為Downloader，它控制組件的下載和Poller屬性：AppUpdater的第二個子組件是Poller,Poller控制更新檢查。

　　(1)AutoStart:布爾值，在應用程序啟動時控制Poller 是否應當開始輪詢或它是否應當等待直到有計劃的更新查詢開始。

　　(2)DownloadOnDetection:布爾值，控制Poller 在一個新的更新發現時是否立即開始下載更新，或者是否通過調用DownloadUdpate() 方法開始顯式下載。

　　(3)InitialPollInterval:應用程序啟動后在第一次執行更新檢查前等待的秒數。

　　(4)PollInterval:第一次更新檢查之后，PollInterval 控制后續每次更新檢查之間間隔的秒數，注意：默認為每30 秒進行一次檢查；顯然，你會希望你的應用程序減少更新檢查的頻率。

　　所有這一切完成之后，你的屬性表格看起來應當是下面這個樣子：

Samples\SampleApp\SampleApp_Complete目錄包含應用程序正確安裝的一個版本。

　　安裝：

　　(1)DownloadRetryAttempts:在下載期間如果有錯誤發生（比如Web 服務器宕機）downloader 會稍后重試。這個屬性控制downloader 認為是徹底的應用程序更新錯誤之前重試網絡請求的次數。

　　(2)SecondsBeteweenDownloadRety:重試網絡請求之前等待的秒數。

　　(3)UpdateRetryAttempts: 在更新期間如果發生嚴重錯誤，（例如downloader 超過了試圖重試的次數），就會產生一個應用程序更新錯誤。默認的，將會停止試圖更新。但是在應用程序下一次啟動時會試圖恢復（比如更新Web 服務器可能會宕機好幾天）。這個屬性控制試圖更新的次數。如果超過這個值，updater 就會取消更新，重置它的狀態并返回更新檢查。

　　(4)ValidateAssemblies: 這個屬性控制下載程序集有效完成的級別。更多信息參見這篇文章的安全一節。

　　第四步：生成并在客戶端部署應用程序V1版本。

　　在SampleApp項目中，打開AssemblyInfo.cs文件。將AssemblyVersion的值從“1.0”修改為“1.0.0.0”。這會引起在生成程序集時獲得值為“1.0.0.0”.. 的標記，該標記代替VS.NET通常指定為遞增的值。

　　1. 生成應用程序。

　　2.從壓縮文件中將Samples\SampleApp\SampleApp_ClientSetup目錄拷貝到你的本地機器上。要注意此目錄已經包含了AppStart.exe。AppStart.config已經設置為指向1.0.0.0目錄并且啟動SampleApp.exe。

　　從SampleApp的release目錄下拷貝SampleApp（Appupdater.dll，SimpleForm.dll和SampleApp.exe）

　　到客戶端SampleApp_ClientSetup\1.0.0.0目錄下。至此，一個功能完整的應用程序版本已被“安裝”到了客戶端，可以通過運行AppStart.exe來執行。

　　第五步：安裝Web服務器

　　在這一步我們將安裝Web服務器以提供更新輪詢功能。.NET應用程序更新組件使用HTTP-DAV來下載應用程序更新，因此需要一個支持HTTP-DAV的Web服務器。Windows 2000上的IIS5.0和更新的操作系統都支持HTTP-DAV。

　　1.將Samples/SampleApp_ServerSetup目錄拷貝到你的Web服務器上的wwwroot目錄下。

　　2. 將SampleApp的V1版本拷貝到Web服務器的1.0.0.0文件夾。

　　3. 在Web服務器上為SampleApp_ServerSetup目錄啟用IIS的“目錄瀏覽”權限。

　　第六步：自動更新應用程序

　　OK，.. 現在是時間來通過自動安裝一個新版本來看看以上這些艱苦工作的結果了。

　　1. 如果你部署在客戶端的SampleApp版本沒有運行，加載它讓它運行，記得使用AppStart.exe。

　　2. 回到VS.NET并在SampleApp窗體中做一些可以被注意到的修改（比如修改背景色）。

　　3. 將AssemblyInfo.cs的版本信息改為2.0.0.0。

　　4. 重新生成。

　　5. 回到Web服務器并生成一個和1.0.0.0目錄同等的目錄2.0.0.0。從release生成目錄下將新版本應用程序拷貝到Web服務器上新建的2.0.0.0目錄下。

　　6.打開UpdateVersion.xml 并修改AvailableVersion為2.0.0.0。修改ApplicationURL為指向新的2.0.0.0路徑。

　　7. 保存對UpdateVersion.xml所做的修改。

　　一旦你保存了新的UpdateVersion.xml，在30秒之內，運行中的SampleApp拷貝將會探測到新的可用版本。

　　四、按需安裝、安全、可擴展性及調試

　　(一)按需求安裝

　　所謂按需求安裝，指只有主可執行程序被顯式安裝到客戶機上。應用程序剩下的部分可以根據基本需要自動下載和安裝。

　　通過.NET應用程序更新組件的AutoFileLoad屬性來啟動按需求安裝。你必須仔細考慮在你的應用程序中程序集邊界所處的位置以及什么動作會引起程序集被下載。由于程序集的下載涉及到網絡輸入輸出，因此下載所花費的時間是可變的。在程序集下載期間，應用程序會被凍結等待程序集下載完成。

　　(二)部署安全

　　自動安裝應用程序更新的能力具備很多好處，但它也伴隨著一些潛在的危險。當你使得安裝更新變得簡單時，如果不小心，你也可能使得安裝惡意代碼變得簡單。有兩種危險，第一種危險是有人會用自己的Web服務器欺騙用來部署更新的Web服務器。他們可能會利用那臺Web服務器在你的應用程序路徑安裝一個病毒程序。阻止欺騙或其它通過網絡進行的不正當干預的最簡單的方法是使用HTTPS。要和.NET應用程序更新組件一起使用HTTPS，可以簡單地用HTTPS URLs來代替HTTP URLs。當然，HTTPS 不是銀彈。使用HTTPS有兩個問題，第一是可伸縮性。使用HTTPS需要服務器加密所有從Web服務器上下載的文件。如果一個應用程序的更新文件很大，加密更新文件的代價會使服務器的負擔過重。使用HTTPS的另一個問題是它對第二種安全危險毫無益處。第二種危險是黑客既可能從內部也可能從外部來攻擊你的服務器。一旦攻擊成功，則有可能意味著成百上千的客戶端也通過自動更新遭受連累，這種情況將是災難性的。

　　為解決這個問題，.NET 應用程序更新組件使用給.NET程序集添加強名稱的特性來驗證所下載的程序集。如果.NET應用程序更新組件檢測到下載期間一個程序集不是使用你的密鑰簽名的，下載就會取消。這意味著只有擁有你的應用程序私鑰的人才能夠建立可自動部署的更新文件。

　　要驗證程序集有效，.NET應用程序更新組件驗證你當前安裝的應用程序可執行程序的公鑰和下載的更新的公鑰是否匹配。如果兩個程序集以相同且保密的私鑰簽名，那么嵌入的公鑰也就相同。因為被 CLR加載的程序集為了驗證它的公鑰，CLR計算它正常的哈希值檢查來保證程序集實際上就是真正的程序集而不是被做了手腳的程序集。為了能夠在下載時驗證，可以給你所有的應用程序集添加強名稱并將.NET應用程序更新組件的ValidateAssemblies屬性設置為true。

　　在下載時進行程序集驗證會起很大的作用，但實際上，應用程序會經常有不同私鑰簽名的組件。比如，你的應用程序可能有兩個文件：使用你的私鑰簽名的可執行程序集和另一個包含你購買的應用在你的應用程序中的第三方圖表控件的dll程序集。第三方程序集可能使
用第三方而不是你自己的私鑰來簽名。使情況變得更為復雜的是，在你的應用程序中用來簽名程序集的有效私鑰的設置隨著版本號的改變可能會發生變化。你該如何自動更新那些應用的類型？為解決這個問題，你可以在你的應用程序中生成一個包含有效公鑰的列表的程序集。將該程序集使用應用程序的主私鑰（應用程序的exe 文件簽名的密鑰）簽名并把該程序集放到Web服務器上和應用程序更新文件一起的目錄下。在更新下載過程開始之前，.NET應用程序更新組件將會檢查Web 服務器上應用程序更新目錄下一個名為"AppUpdaterKeys.dll"的的程序集。如果存在，該程序集就會被下載。該程序集會被拿來和主應用程序的公鑰對比驗證。如果簽名有效，密鑰列表會被提取出來。從此之后，任何處于該列表中的密鑰會被認為是更新文件的有效簽名。

　　有關安全方面推薦的方法是使用HTTPS URLs來實現更新檢查。這會提供第一級別的欺騙保護。對于更新下載，最好不要使用HTTPS RLs以避免使你Web服務器的負荷過重。而是給你的應用程序的程序集添加強名稱并使用程序集驗證特性。

　　(三)可擴展性

　　在這篇文章前面講過的示例中我們簡單地通過拖放一個組件到應用程序中并設置一些屬性來實現自動部署。

　　雖然這在許多應用程序中工作的很好，但在一些應用程序中會需要高級別的控制，這只能通過寫代碼來獲得。我們可以編寫自己的代碼來替換掉.NET應用程序更新組件標準過程，使用重寫的CheckForUpdate()和ApplyUpdate()方法來定制檢查和更新行為。

　　(四)調試

　　這一節將指出一些首選的調試選項，以及描述使用該組件的用戶大多數常見的問題。

　　.NET應用程序更新器在和AppStart.exe相同的目錄下生成一個名為AppUpdate.log的隱藏日志文件。

　　所有的更新成功和失敗信息都記錄在該日志中。當有一個特殊的客戶端不能成功更新時日志文件會特別有用。

　　你可以使用日志來判斷在什么時間以及是如何更新失敗的。另外，.NET應用程序更新組件使用.NET框架的Debug類來輸出大量有用的信息。如果你在調試器中運行你的應用程序，你會在輸出窗口中看到這些信息。你可以循著.NET應用程序更新器的記錄重點觀察并找到出
問題的地方。

　　如果由于某種原因，你無法使得.NET應用程序更新器工作，在你深入調試之前請確定以下幾點，你遇到的問題很可能就是如下之一：..

　　. 你是否將IIS目錄瀏覽給打開了？如果沒有，更新器將不會下載安裝任何文件。

　　. 你是否正確的部署了一切并正確設置了URL？

　　. 如果你的應用程序安裝在program files目錄下，確定你是該機的超級管理員或超級用戶嗎？如果不是，你將不會有寫權限來更新應用程序。

　　. 你是在應用程序的主用戶界面線程中生成AppUpdater對象的嗎？如果不是，更新器將不能顯示用戶界面并且在激發事件回到用戶界面時失敗。

　　. 是否更新成功，但應用程序使用新的更新自動重啟時失??？.NET 應用程序更新組件試圖通過調用Application.Exit方法來退出應用程序。然而，該方法并不能保證關閉一個應用程序。如果你生成并遺留了單獨的線程在運行，該方法就無法關閉進程。保證所有線程終止的解決的方案是通過調用Application.OnExit事件，或者掛鉤.NET應用程序更新器的OnUpdateComplete事件并自己處理關閉。

　　五、總結

　　客戶端應用程序部署方便是. NET框架第一個版本的重要的目標。用.NET框架建立解決部署問題的客戶端應用程序是一種很好的技術。部署方便仍然是未來.NET框架新版本的一個重要目標。就方案而言，這里描述的.NET應用程序更新組件代表了我們的一些想法，在未來版本的.NET框架中我們將可以直接使用。然而，在那個時候到來之前的這段期間，.NET應用程序更新組件不失為開始建立自動更新應用程序的一種重要的方法。

原文轉自：http://www.anti-gravitydesign.com