可能的原因及解决办法： #

• 预编译模式选择错误
  如果你在VS发布时选了「允许更新预编译站点」（对应updatable="true"参数），这种模式下ASP.NET会保留原始的.aspx/.ascx文件，并且会在运行时检查这些文件的修改时间是否比.compiled文件新，一旦发现差异就会触发重新编译。
  解决办法：重新发布时选择「不允许更新预编译站点」（updatable="false"），这种模式下所有页面都会被完全编译成DLL，不会保留可修改的页面文件，ASP.NET会直接加载预编译的DLL而不会尝试重新编译。

• 文件权限不足
  IIS应用池的运行账户（默认是IIS AppPool\<你的应用池名称>）没有对站点根目录下的.compiled文件和bin文件夹里的DLL/PDB文件的读取权限，导致ASP.NET无法识别预编译的状态，只能重新编译。
  解决办法：给应用池账户添加站点物理路径的读取权限：

  1. 右键站点物理路径文件夹 → 「属性」→ 「安全」标签
  2. 点击「编辑」→ 「添加」，输入应用池账户名（比如IIS AppPool\MyAppPool）
  3. 勾选「读取」和「读取及执行」权限，点击确定保存。

• Web.config编译配置冲突
  如果你的web.config里的<compilation>元素设置了batch="true"或者optimizeCompilations="false"，可能会导致ASP.NET强制批量编译，忽略已有的预编译文件。另外开启debug="true"也会触发额外的编译检查。
  解决办法：调整web.config的编译配置：

  <compilation debug="false" batch="false" optimizeCompilations="true" targetFramework="4.5" />
  

• 部署文件不匹配或缺失
  可能存在以下情况：

  • 有些.aspx/.ascx文件没有被正确预编译，仍然保留在站点中，且修改时间晚于.compiled文件
  • .compiled文件和对应的DLL文件版本不匹配（比如发布后又修改了DLL但没更新.compiled）
    解决办法：
  1. 重新执行完整的预编译发布，确保所有页面都被编译，若用不可更新模式，删除站点中残留的未预编译的.aspx/.ascx文件
  2. 验证每个.compiled文件里的assembly属性是否对应bin文件夹里的DLL名称和版本。

• 应用池.NET版本配置错误
  如果你的IIS应用池设置的.NET CLR版本是v2.0而不是v4.0，ASP.NET 4.5的预编译文件无法被正确识别，导致重新编译。
  解决办法：

  1. 打开IIS管理器 → 应用池 → 找到你的应用池
  2. 右键 → 「基本设置」，将.NET CLR版本改为「v4.0.30319」
  3. 重启应用池和站点。

额外验证步骤 #

部署完成后，可以检查站点根目录下的PrecompiledApp.config文件（预编译后自动生成），确保里面的updatable属性是false（如果用的是不可更新模式）：

<?xml version="1.0" encoding="utf-8"?>
<precompiledApp version="1" updatable="false"/>

如果这个文件缺失或者updatable设为true，也会导致ASP.NET尝试重新编译。

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