.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程序集的热部署

回答

相关问题