我有一个IIS8，并且已经部署了一个asp.net核心网站（使用asp.net核心模块）
为了不时地用新功能更新站点，我将站点克隆到另一个文件夹中并更改了Web配置，以便asp.net核心模块从该文件夹启动应用程序。然后，我将新文件复制到网站根目录中，然后再次更改Web配置以指向根目录中的初始路径。
更改Web配置应触发（并且确实）应用程序重新启动。旧进程应该死掉（在完全关闭后），新进程（从新路径开始）应该开始。
问题在于旧进程根本不会消失。产生了一个新文件，但是旧文件就在那里，我必须从任务管理器中手动将其杀死，否则我将无法覆盖新文件。
我认为，由于旧进程应正常终止，因此必须有一个长期运行的请求才能使旧进程保持活动状态。我唯一想到的是，我在浏览器页面中使用的signalR客户端是保持与服务器的连接，因此可以使旧进程保持活动状态。
为了检验这一理论，我在浏览器中打开了该站点，并在任务管理器中观看了任务。应用程序的过程就在那里。我更改了Web配置文件，并在同一地址上打开了另一个标签。一个新的过程出现在任务管理器中。但是即使经过了几分钟，那辆旧车仍然在那里。我怀疑第一个浏览器选项卡与旧的asp.net核心进程保持连接。所以我关闭了第一个标签。我关闭它不超过一秒钟，旧过程终止了。
所以我的理论正确吗？在更改web.config之后，signalR客户端是否阻止asp.net核心进程正常关闭？服务器signalR组件不应该发信号通知客户端断开连接（或发送断开连接的事件）然后让进程终止吗？
我该如何克服这个问题？我希望在web.config更改后，旧进程终止，而不是永远挂在那里并不得不手动将其杀死。
答案 0 :(得分：0)
很难确切地说，因为我什至从未考虑做您正在做的事情，但是我的感觉是这取决于更改web.config。您实质上是在孤立另一个Kestrel进程。是的，更改web.config会触发重新启动，但是它会在附加的进程上启动。当IIS看到此更改的web.config时，它没有看到该位置运行的进程（因为您更改了位置），因此只需启动此新进程即可。
如果您已经部署到另一个文件夹，则只需在IIS中编辑站点并将文档根目录更改为该新目录即可。这将导致IIS停止当前正在运行的站点（即您现有的进程），然后再次启动它，但是现在在新的文档根目录下。然后，您可以根据需要删除旧文件夹。