无法加载程序集NAME_OF_ASSEMBLY，求ASP.NET项目部署故障排查方案

这问题我之前帮团队排查过类似的，结合你描述的细节——错误里显示完整正确的程序集名称、本地正常同事却报错，给你几个针对性的排查方向，按优先级来：

1. 先确认程序集的完整性与版本匹配 #

• 检查同事机器网站的bin目录，确保那个依赖的母版页项目NAME_OF_ASSEMBLY.dll和你本地的完全一致：右键属性看版本号、用PowerShell的Get-FileHash命令对比文件哈希。有时候复制过程中文件损坏，或者版本不一致（比如你本地是Debug编译，同事拿到的是旧的Release版本）都会导致加载失败。
• 如果这个.dll本身还依赖其他第三方程序集，也要确认这些依赖项是否都在bin目录里——可以用Dependency Walker工具检查它的依赖链，有没有缺失的项。

2. 检查IIS应用池的权限与运行环境 #

• 确认同事机器的IIS应用池身份（比如ApplicationPoolIdentity、Network Service）对网站的bin目录有读取权限：右键bin目录→属性→安全，添加对应身份并授予读取权限。有时候部署后权限没继承，导致IIS进程读不到.dll。
• 检查应用池的.NET Framework版本是否和项目一致：比如你项目用的是4.8，同事的应用池设成了4.0，肯定会出问题。在IIS管理器里找到对应应用池，查看".NET CLR版本"设置。

3. 清理ASP.NET临时文件缓存 #

ASP.NET会把编译后的页面缓存到临时目录，有时候旧的缓存文件会和新程序集冲突。让同事执行以下步骤：

1. 停止对应的IIS应用池
2. 删除C:\Windows\Microsoft.NET\Framework\v[你的框架版本]\Temporary ASP.NET Files下对应网站的子文件夹（或者直接清空整个目录，不影响其他站点的话）
3. 重启应用池和网站

4. 检查程序集的强名称与GAC冲突 #

如果你的NAME_OF_ASSEMBLY.dll是强名称程序集，确认同事机器的GAC里有没有同名但版本不同的程序集——ASP.NET会优先加载GAC里的程序集，如果版本不匹配就会报错。可以用gacutil /l NAME_OF_ASSEMBLY命令查看GAC里的条目，如果有冲突，要么更新GAC里的版本，要么在web.config里添加绑定重定向：

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="NAME_OF_ASSEMBLY" publicKeyToken="你的公钥令牌" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-当前版本" newVersion="当前版本" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

5. 启用详细错误日志定位根因 #

500错误的默认提示不够详细，可以让同事开启ASP.NET的详细错误日志：

1. 在web.config里修改customErrors节点：

<customErrors mode="Off" />

2. 同时开启IIS的失败请求跟踪（FRT）：在IIS管理器里选中网站→功能视图→"失败请求跟踪规则"，添加规则跟踪500状态码，生成的日志会详细显示程序集加载失败的具体原因（比如找不到依赖、权限不足等）。

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