我们有一个应用程序在生产服务器上作为 Windows 服务运行。应用程序主要在部署边界上划分为几个程序集。我想简化对应用程序程序集的热修复部署。目前我执行以下步骤来部署热修复。 （我们有一个用于暂存的生产环境的副本，所以一切都必须做两次）
我想我希望将 dll 上传 (SFTP) 到预设文件夹，并让应用程序获取新的 dll。
我考虑过的一个解决方案是在服务器上运行一个单独的服务。我们将其称为修补程序部署服务。它将监视文件系统中的新文件并执行上面列表中的步骤 2-6。
感谢任何见解。我对其他替代方案持开放态度，只要它们能减少部署摩擦。
【问题讨论】：
标签： .net deployment windows-services
拥有单独的服务可能是您的最佳选择。
您可以在单个服务中执行此操作。但是，实现服务自我更新所需的“技巧”有点难以实施。
您需要做的就是让您的服务作为一个非常轻量级的 shell 服务启动。然后，它可以启动一个单独的、绝缘的 AppDomain，并让该 appdomain 加载您的服务的程序集、初始化和运行。
稍后，当您想要更新时（可以通过服务可以获取的任何事件触发，包括将新程序集复制到更新文件夹 [通过 FileSystemWatcher]、通过网络明确告知它等]），它会需要触发一种方法来告诉内部 AppDomain 的类型停止，然后 卸载 AppDomain。此时，它可以执行上述步骤 3 和 4。然后，它只需要重新加载 AppDomain，重新运行它的初始化等。
由于服务将位于单独的 AppDomain 中，因此这一切都可能发生在一个可执行文件中，而无需停止服务。当 AppDomain 被卸载时，它加载的程序集也被卸载。
这里唯一的要求是，您必须确保不要将任何类型从构造的类型传递到主 AppDomain，否则您会将程序集加载到主 AppDomain 中。这将阻止您在运行时更新它们。
【讨论】：
在我们的构建服务器中，我们使用 powershell 脚本远程停止服务，复制新文件，然后重新启动服务。
【讨论】：
我会看看 Castle Windsor 作为“热插拔”程序集的一个不错的选择。
它是一个高级且支持良好的 IoC/DI 框架，除了将文件实际移动到目标机器上之外，它有助于完成您提到的许多任务。不过，CW 会很好地处理实际的管道。
【讨论】：