ASP.NET 2.0 上传新dll文件到bin目录后出现运行时错误如何解决？

第一步：先获取真实报错信息 #

你遇到的customErrors配置不生效是共享主机的常见情况：

共享主机的IIS站点级/父级web.config优先级高于你应用根目录的web.config，部分主机会默认锁定customErrors配置，或者DLL加载错误发生在应用读取根目录web.config之前，导致你的Off配置不生效。

优先用以下方式获取真实错误，不需要依赖前端错误页：

• 本地搭建.NET Framework 2.0运行环境，把新增的DLL放到本地测试站点的bin目录，直接运行获取完整错误栈
• 登录共享主机的控制面板，查找IIS应用日志、站点错误日志入口，直接拉取官方记录的错误详情

常见触发原因及修复方案 #

• DLL框架版本不兼容 #

  若你新增的DLL是面向.NET Framework 3.0及以上版本编译的，ASP.NET 2.0 runtime无法加载，会直接触发启动错误。
  修复：确认所有新增DLL的目标框架为.NET Framework 2.0，自行编译类库时，在项目属性的目标框架选项中选择对应版本，不要引入高版本依赖类库。

• DLL权限配置异常 #

  共享主机的bin目录默认仅给应用池身份开放读取/执行权限，新上传的DLL可能继承了上传临时目录的权限，缺少对应执行权限。
  修复：通过主机提供的文件管理器，将新增DLL的权限调整为和bin目录下原有正常运行的DLL权限一致，勾选读取、读取和运行权限即可。

• 架构不匹配 #

  若新增DLL仅编译为32位版本，而主机应用池为64位且关闭了32位程序支持，会触发DLL加载失败。
  修复：优先使用Any CPU架构编译的DLL，若必须用32位DLL，联系主机提供商开启应用池的32位程序支持。

• 依赖缺失或强命名冲突 #

  新增的DLL可能存在未同步上传的依赖类库，或是强命名程序集的版本和应用现有引用不匹配，都会触发启动错误。
  修复：用ildasm.exe（.NET 2.0 SDK自带的程序集检查工具）查看新增DLL的所有依赖项，将所有依赖的DLL同步上传到bin目录；如果是强命名版本冲突，在web.config的<runtime>节点下添加程序集绑定重定向配置，示例格式如下：

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="你的程序集名称" publicKeyToken="程序集公钥Token" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-当前版本号" newVersion="当前版本号" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  

• 父级配置覆盖 #

  若需要强制让你的customErrors配置生效，可在web.config中用<location>节点包裹现有配置，阻止父级配置继承：

  <location path="." inheritInChildApplications="false">
    <system.web>
      <customErrors mode="Off" />
      <!-- 其他原有system.web下的配置 -->
    </system.web>
  </location>
  

快速验证方法 #

你可以先创建一个最小化测试类库：用.NET Framework 2.0新建空类库，仅写一个无依赖的静态方法，本地测试无异常后上传到主机bin目录，若不报错则说明你之前使用的DLL本身存在兼容性/依赖问题；如果最小测试DLL也报错，直接联系主机提供商确认应用池.NET版本是否为2.0，是否存在bin目录写入限制、程序集加载限制。

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