我们在生产服务器上有一个作为
Windows服务运行的应用程序.应用程序主要在部署边界上划分为多个程序集.我想简化热修复程序到应用程序集的部署.目前,我执行以下步骤来部署修补程序. (我们有一个重复的生产环境用于升级,所以一切都必须完成两次)
>登录服务器
>停止服务
>备份当前部署的DLL
>替换为修补程序(复制现有DLL上的修补程序)
>重启服务
>在意外加载错误的情况下回滚(尚未发生)
我想我想要的是将一个dll上传(SFTP)到预设文件夹并让应用程序拿起新的dll.
我考虑过的一个解决方案是在服务器上运行单独的服务.我们称之为修补程序部署服务.它将查看新文件的文件系统,并从上面的列表中执行步骤2-6.
任何见解都表示赞赏.我对其他替代方案持开放态度,只要它们减少部署摩擦.
拥有单独的服务可能是您的最佳选择.
您可以在单个服务中执行此操作.但是,使服务自我更新所需的“技巧”有点难以实现.
您需要做的就是让您的服务从一个非常轻量级的shell服务开始.然后,它可以启动一个单独的,绝缘的AppDomain,并让该appdomain加载服务的程序集,并初始化和运行.
稍后,当您想要更新时(可以通过服务可以接收的任何事件触发,包括将新程序集复制到更新文件夹[通过FileSystemWatcher],通过网络明确告诉它等),它将需要触发告诉内部AppDomain的类型停止,然后卸载AppDomain的方法.此时,它可以做第3步和第3步. 4以上.然后,它只需要重新加载AppDomain,重新运行它的初始化等.
由于服务将位于单独的AppDomain中,因此可能会在一个可执行文件中发生,而不会停止服务.卸载AppDomain时,也会卸载它加载的程序集.
这里唯一的要求是,您必须确保不要将任何类型从构造的AppDomain传递到主AppDomain,或者您将程序集加载到主AppDomain中.这会阻止您在运行时更新它们.
