IIS8下CGI模块加载.NET程序集失败的技术排查求助

我之前处理过好几起类似的Progress老程序在IIS CGI环境下加载.NET程序集的故障，结合你提供的Fusion日志信息，咱们一步步拆解问题、排查根源：

核心问题拆解 #

你遇到的0x80070002错误虽然提示“找不到文件”，但实际原因往往不是文件真的缺失——毕竟你已经确认Progress.NetUI.dll在C:\MiaWeb\bin目录。更可能的是：

• CGI进程的当前工作目录不是bin目录，导致CLR默认探测路径不对
• IIS的权限限制，使得进程无法读取该dll文件（Windows经常把权限不足伪装成“文件不存在”）
• OpenEdge老式应用的特殊加载逻辑，和IIS CGI的运行上下文不兼容

逐步排查步骤 #

1. 确认CGI进程的实际工作目录 #

CLR默认会从进程的当前工作目录开始探测程序集，但IIS里的CGI进程默认工作目录可能不是你放dll的C:\MiaWeb\bin。你可以：

• 用Process Explorer找到nph-cybermia.exe进程，查看它的Working Directory属性，确认是不是bin目录
• 临时修改程序，在启动时把Environment.CurrentDirectory的值写入日志文件，直接查看进程的当前路径

2. 检查IIS CGI的配置细节 #

打开IIS管理器，找到你的站点的处理程序映射：

• 找到对应nph-cybermia.exe的CGI条目，右键点击“编辑”，进入“高级设置”
• 确认“可执行文件”的路径是正确的\\?\C:\MiaWeb\bin\nph-cybermia.exe
• 重点检查工作目录是否设置为C:\MiaWeb\bin——很多时候这里默认是IIS的系统目录，导致CLR找不到dll

3. 验证权限是否足够 #

即使文件存在，IIS应用池的运行身份可能没有读取C:\MiaWeb\bin目录的权限：

• 找到你的应用池，查看它的“标识”（比如默认是IIS AppPool\DefaultAppPool）
• 右键C:\MiaWeb\bin目录，选择“属性”→“安全”，添加该标识的读取和执行权限
• 测试是否还会出现错误（记得重启应用池生效）

4. 脱离IIS环境测试 #

在命令行里切换到C:\MiaWeb\bin目录，直接运行nph-cybermia.exe：

• 如果能正常加载程序集，说明问题100%出在IIS的CGI配置上，集中排查工作目录和权限
• 如果还是报错，那就是程序本身的加载逻辑问题，需要检查OpenEdge的.NET集成配置

针对性解决方法 #

方法1：修正CGI工作目录 #

在IIS处理程序映射的高级设置里，把“工作目录”明确设置为C:\MiaWeb\bin，这样CGI进程启动时就会以这个目录为当前工作目录，CLR就能直接探测到同目录的Progress.NetUI.dll。

方法2：强制指定程序集探测路径 #

如果工作目录无法修改，或者OpenEdge程序有特殊路径逻辑，可以给nph-cybermia.exe添加一个配置文件（命名为nph-cybermia.exe.config，放在同目录），手动指定CLR的探测路径：

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <!-- privatePath是相对于进程工作目录的路径，这里直接指向bin目录 -->
      <probing privatePath="C:\MiaWeb\bin"/>
    </assemblyBinding>
  </runtime>
</configuration>

方法3：排查OpenEdge运行时配置 #

老式Progress OpenEdge应用可能依赖自身的.NET集成组件：

• 确认OpenEdge的安装目录是否添加到了系统PATH环境变量中
• 检查OpenEdge是否有专门的.NET配置工具，确保Progress.NetUI.dll被正确注册（注意你的dll未强命名，无法安装到GAC，所以不用考虑GAC注册）

额外调试工具 #

• Fusion日志查看器（fuslogvw.exe）：在C:\Windows\Microsoft.NET\Framework\v4.0.30319目录下运行，生成更详细的绑定日志，对比直接运行和IIS下的日志差异，看CLR到底尝试了哪些路径
• Process Monitor：跟踪nph-cybermia.exe的文件访问记录，能直观看到它尝试访问Progress.NetUI.dll的路径，以及是否有访问被拒绝的情况

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