Temporary ASP.NET Files变更引发ASP.NET应用重启问题咨询

核心疑问1：Temporary ASP.NET Files目录下的文件变更为何会触发应用重启 #

ASP.NET 4.x 的HostingEnvironment初始化时，会通过FileSystemWatcher注册一组敏感路径的变更监控，只要监控路径下的文件发生修改、删除、属性变更，就会直接判定当前运行环境失效，触发应用域卸载和重启流程。
这组监控路径不止包含站点自身目录下的web.config、bin文件夹、App_Code等路径，默认也覆盖Temporary ASP.NET Files下当前应用对应的编译缓存目录。你提到的hash.web是该目录下的缓存哈希标记文件，运行时用它校验编译缓存的有效性，只要这个文件出现变更，不管是正常的缓存更新还是外部进程误操作，都会直接触发重启。
无人工操作场景下这类变更90%以上是杀毒软件导致：实时扫描、勒索防护模块在扫描该目录时，可能修改文件最后写入时间、写入扫描标记、甚至短暂重写文件做安全校验，刚好命中监控规则。

核心疑问2：预编译部署的应用为何仍会生成临时目录文件 #

这里存在普遍认知误区：Web Deploy阶段的预编译，仅会提前编译视图、业务代码类，跳过首次请求的视图编译和代码编译耗时，不会禁用ASP.NET运行时的临时目录写入逻辑。
不管预编译参数怎么配置，应用启动时运行时都会往临时目录写入三类必须的文件，和预编译与否无关：

• 程序集影子拷贝（Shadow Copy）文件：ASP.NET 会把bin目录下的dll拷贝到临时目录再加载，避免运行时锁定部署目录的dll
• 运行时动态生成的代码/配置：包括OWIN启动类的动态代理、程序集绑定重定向动态配置、路由注册缓存等
• 缓存校验文件：也就是你看到的hash.web，用来标记当前缓存的版本

关于CONFIG变更触发重启的补充说明 #

无人工操作触发的CONFIG变更重启，除了Windows Update更新.NET Framework全局配置（machine.config、根级web.config）的场景外，同样大概率是安全软件扫描配置文件时触发的属性变更，和hash.web变更的触发逻辑一致。

可落地的规避方案 #

• 给对应版本的Temporary ASP.NET Files目录（64位路径为C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\，32位路径为C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\）添加杀毒软件排除规则，禁止实时防护扫描、修改该目录下的文件
• 可以在站点web.config中为应用配置独立的临时编译目录，避开系统默认路径，再给新目录加杀软排除，配置示例如下：

<system.web>
  <compilation tempDirectory="D:\SiteRuntimeCache\YourAppIdentity\" />
</system.web>

• 若需要确认根因，可以用Process Monitor工具在复现阶段监控对应文件的写入进程，即可定位到触发变更的具体程序
• OWIN技术栈场景下，建议在web.config中明确指定启动类，关闭运行时自动扫描启动类的逻辑，减少运行时对临时目录的额外读写：

<appSettings>
  <add key="owin:AutomaticAppStartup" value="false" />
  <add key="owin:appStartup" value="YourApp.Startup, YourAppAssembly" />
</appSettings>

内容的提问来源于stack exchange，提问作者user507278