ASP.Net网站热修复失效求助：替换DLL后修改未生效

首先明确回答你的核心疑问：代码后置文件（.cs/.vb）的逻辑确实会编译到所属Web项目生成的DLL中，所以你替换DLL的思路是完全正确的，只是可能还有一些容易忽略的细节没覆盖到。我碰到过好几个类似的场景，给你梳理下具体的排查方向：

• 先确认你替换的是正确的DLL版本
  别小看这个，很多时候我们会犯低级错误：比如编译的是Debug版本却替换了Release文件夹的DLL，或者编译过程中其实有报错但没注意到，导致DLL根本没更新。你可以右键查看DLL的「修改时间」，确认是你编译后的时间；或者用ILSpy这类工具反编译DLL，直接查看对应的代码后置类，看那个整数类型已经改成32位了——这一步能直接排除“拿错DLL”的低级问题。

• 安全清理Temporary ASP.NET Files中对应网站的缓存
  你担心删除会影响其他用户，其实可以精准清理：

  1. 先找到你的网站对应的应用程序池标识（比如Network Service、IIS AppPool\你的池名称）
  2. 打开C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\（如果是64位系统就看Framework64目录）
  3. 找到以你的网站应用程序池命名的子文件夹，或者对应网站虚拟路径的文件夹，只删除这个文件夹里的内容，不会影响其他网站。
  4. 更稳妥的方式是先执行iisreset /stop停掉IIS，清理后再iisreset /start重启，确保临时文件被完全替换。

• 检查是否存在其他加载DLL的路径
  ASP.NET可能从多个位置加载DLL：

  • 网站根目录下的子文件夹（比如有些独立模块会放在子目录的bin里）
  • web.config中<runtime><assemblyBinding>或者<probing>节点指定的额外搜索路径
  • 如果你的网站是Web Site项目（不是Web Application），可能会有App_Code文件夹里的动态编译文件，这时候即使替换bin的DLL，动态编译的旧代码还会生效——这种情况你需要检查App_Code里有没有对应的类文件，或者删除App_Code的编译缓存。

• 确认应用程序池的.NET版本匹配
  比如你编译的DLL是基于.NET Framework 4.0，但应用程序池设置的是.NET 2.0，这时候IIS会加载兼容模式的DLL，导致你的修改不生效。去IIS管理器里查看应用程序池的「.NET Framework版本」，确保和你编译的版本一致。

• 检查影子复制和页面缓存机制
  ASP.NET默认启用「影子复制」，会把bin里的DLL复制到临时目录加载，有时候回收应用池后影子复制的文件没及时更新——这时候清理临时文件就能解决。另外，还要检查页面是否启用了输出缓存（比如页面顶部的<%@ OutputCache %>指令，或者web.config里的缓存配置），如果有，需要先禁用缓存再测试。

• 最后再确认GAC的可能性
  虽然你说不抱希望，但还是要再检查一次：打开命令提示符，执行gacutil /l 你的DLL名称，如果能找到对应的条目，说明GAC里有旧版本，ASP.NET会优先加载GAC里的DLL，这时候需要用gacutil /u 你的DLL名称卸载旧版本。

按照这个顺序排查，应该能快速定位到问题所在。

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