我们有一个在生产服务器上作为Windows服务运行的应用程序。该应用程序主要在部署边界上划分为几个程序集。我想简化对应用程序集的修补程序的部署。当前,我执行以下步骤来部署热修复程序。 (我们有一个生产环境的副本用于暂存,因此所有操作都必须完成两次)
登录服务器
停止服务
备份当前部署的dll
替换为修补程序(通过现有dll复制修补程序)
重新启动服务
万一发生意外的加载错误(尚未发生),请回滚
我认为我想要将dll上传(SFTP)到预设文件夹,并让应用程序选择新的dll。
我考虑过的一种解决方案是在服务器上运行单独的服务。我们称其为修补程序部署服务。它将监视文件系统中是否有新文件,并从上面的列表中执行步骤2-6。
任何见解均表示赞赏。我愿意接受其他替代方案,只要它们可以减少部署摩擦。
最佳答案
拥有单独的服务可能是您的最佳选择。
您可能会在一项服务中执行此操作。但是,使服务自我更新所需的“技巧”有点难以实现。
您需要做的就是让您的服务以轻量级的shell服务开始。然后,它可以启动一个单独的,隔离的AppDomain,并让该appdomain加载服务的程序集,进行初始化并运行。
以后,当您想要更新时(可能通过任何事件触发该服务都可以接收,包括将新程序集的副本复制到更新文件夹中(通过FileSystemWatcher,通过网络明确告知它等)),它将需要触发一种告诉内部AppDomain的类型停止的方法,然后卸载AppDomain。此时,它可以执行上面的步骤3和4。然后,只需要重新加载AppDomain,重新运行其初始化等即可。
由于该服务将位于单独的AppDomain中,因此所有这些都可以在一个可执行文件中发生,而无需停止服务。卸载AppDomain时,也会加载它加载的程序集。
唯一困难的要求是您必须确保不要从构造的类型中将任何类型传递到主AppDomain中,否则将程序集加载到主AppDomain中。这将使您无法在运行时更新它们。
关于.net - .NET程序集的热部署,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/1862289/