gpt4 book ai didi

.net - .net 程序集的热部署

转载 作者:行者123 更新时间:2023-12-04 11:45:42 26 4
gpt4 key购买 nike

我们有一个在生产服务器上作为 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/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com