有没有人有如何修补正在运行的 asp.net 应用程序的示例?我设想的场景是,该应用程序可以向已知的中央服务器寻求更新的版本。将较新的文件下载到临时位置,然后自行修补。
我可以看到的问题是任何文件更改都将被文件观察程序拾取并重新加载应用程序域,这将停止当前的修补过程。我认为写入的每个文件都会触发应用程序的重新加载。
打补丁是什么意思?
如果您的意思是更新,您可以简单地将更新文件复制到应用程序目录。当前活动的请求将使用您的应用程序的最后编译版本完全服务,然后将重新编译以服务后续请求。真的不需要什么特别的。
除非您正在对特定文件进行一些文件监视,否则您可以更新现有的 aspx 文件而不会降低应用程序的速度。下次用户刷新浏览器时,他们会看到页面更新。不过要小心,如果您在页面中添加了额外的服务器控件,并且 DLL 尚未更新,您将遇到问题。
如果您更新应用程序的 web.config 或 DLL 文件,这将触发 ASPNET 工作进程的重新加载,并且任何新用户都将遭受您通常可以预期的“第一次延迟”。
如果您担心这个过程,并且可以承受一点“停机时间”,我建议您创建一个执行以下操作的脚本:
将名为 App_Offline.htm 的文件上传到 Web 应用程序的根目录。IIS 将立即看到此文件并将用户重定向到它,而不进行任何 .NET 处理。您甚至可以在根文件夹中保留一个名为 App_Offline_Disabled.htm 的文件,并在适当的时候简单地重命名它。
复制所有需要更新的文件,根据需要覆盖/重命名/复制。
删除(或重命名)您的 App_Offline.htm 文件,以便 IIS 开始将用户定向到更新的应用程序。如果您正在观看脚本运行,您甚至可以自己访问网站以承担“首次加载”的惩罚,这样您的最终用户就会像往常一样看到漂亮而清晰的东西。
同样,我不知道您是否能以这种方式承受站点的停机时间,但我认为该过程本身很容易编写脚本以提供一个很好的自动化类型过程。
我不知道有任何自动化方法可以做到这一点。似乎只依靠自动构建脚本会更容易将更改推送到您的服务器。
如果您将会话状态保留在外部进程中,您可以更新站点(这将导致重新编译),而您的用户不会被踢出。他们在等待重新编译时只会经历更长的加载时间。
我只是在引发 filewatcher 事件时检查版本信息。如果程序集的版本与您正在考虑修补的活动程序集不同,则继续进行复制。如果不是,那么只需忽略该事件。还有一个问题是,在没有实际版本更改的情况下,为什么要复制到从中检索文件的临时目录?