.net程序集的熱部署

我們有一個作爲生產服務器上的Windows服務運行的應用程序。應用程序主要在部署邊界上分區爲幾個程序集。我想簡化應用程序程序集的熱修復程序的部署。目前我執行以下步驟來部署修補程序。（我們的生產環境升級的副本，所以一切都要進行兩次）.net程序集的熱部署

登錄到服務器
停止服務
備份當前部署的DLL
與修補程序替換（副本在現有的DLL修復程序）
重新啓動服務
回滾意外加載錯誤（的情況還沒有發生，但是）

我想我想要的是上傳（SFTP）一個DLL到預設文件夾，並讓應用程序拿起新的DLL。

我考慮的一個解決方案是在服務器上運行單獨的服務。我們稱之爲修補程序部署服務。它會監視文件系統中的新文件並從上面的列表中執行步驟2-6。

任何洞察力是讚賞。我願意接受其他替代方案，只要他們減少部署摩擦。

來源

2009-12-07 Kim Major

有一個單獨的服務可能是您最好的選擇。

您可能會在單個服務中執行此操作。然而，使服務自我更新所需的「訣竅」有點難以實現。

你需要做的是讓你的服務作爲一個非常輕量級的shell服務開始。然後，它可以啓動一個獨立的絕緣AppDomain，並讓該AppDomain加載您的服務的程序集，並初始化並運行。（通過FileSystemWatcher]將新程序集複製到更新文件夾，通過網絡等方式明確告知它），然後當你想要更新時（可以通過任何事件觸發服務，需要觸發一種方式來告訴內部AppDomain的類型停止，然後卸載AppDomain。此時，它可以執行上述步驟3 & 4。然後，它只需要重新加載AppDomain，重新運行它的初始化等。

由於該服務將位於單獨的AppDomain中，因此這可能全都發生在一個可執行文件中，而不會停止服務。當一個AppDomain被卸載時，它所加載的程序集也被卸載。

這裏唯一的要求很困難，就是你必須確保不從構造的主AppDomain傳入任何類型，否則你會將程序集加載到主AppDomain中。這會阻止您在運行時更新它們。

來源

2009-12-07 19:32:02

ShadowCopyFiles在這裏很大。 – 2009-12-07 19:37:01

是的，儘管有備份要求，但在這種特定情況下可能不是問題。 – 2009-12-07 19:38:58

備份步驟並不困難，它只是我做的一個步驟，可以快速回滾。我對ShadowCopyFiles不熟悉，不得不考慮這一點。 – 2009-12-07 19:43:03

我會看看Castle Windsor作爲「熱插拔」程序集的一個很好的選擇。

這是一個先進且良好支持的IoC/DI框架，可幫助您提及許多任務，除了實際將文件移動到目標機器上。但是，CW的實際管道將很好的照顧。

來源

2009-12-07 19:31:44

我們已經使用了一個IoC容器（Unity），但我不確定這將如何進行加載類型的熱交換。城堡在這方面有什麼？（快速瀏覽網站沒有透露任何信息） – 2009-12-07 19:36:37

是的。你必須深入挖掘，但熱切換是CW的核心目標之一（無論如何，我最後一次看）。Unity不支持熱交換？奇怪。但僅僅是您已經使用DI框架的事實應該可以幫助您輕鬆遷移。 – 2009-12-07 20:05:16

我想這取決於「熱交換」的定義。例如，如果你有幾個接口的實現，你可以解決任何給定的實現。但是我需要在應用程序解決並正在使用之後替換具體的實現。我沒有想到在Unity中尋找這個，但我確信你不能這樣做。在你構建容器和類型被加載後，它幾乎停留在appdomain中（除非我失去了一些東西） – 2009-12-07 20:13:06

從我們的構建服務器，我們使用powershell腳本來遠程停止服務，複製新文件並重新啓動服務。

來源

2009-12-07 19:32:38 David

我們幾乎正是從CruiseControl.NET中完成的。（沒有PowerShell）。 – 2009-12-07 19:38:09

.net程序集的熱部署

回答

相關問題