通过BroadCom ESP执行.NET应用报Could not load file or assembly错误求助

手动运行和调度运行的核心差异是进程启动上下文，以下是可落地的排查方向：

1. 确认进程架构与GAC注册路径匹配 #

• .NET Framework存在两套独立的GAC：32位路径为C:\Windows\Microsoft.NET\Framework\<对应.NET版本>\GAC（.NET 4.x+为C:\Windows\Microsoft.NET\assembly\GAC_32），64位路径为C:\Windows\Microsoft.NET\Framework64\<对应.NET版本>\GAC（.NET 4.x+为C:\Windows\Microsoft.NET\assembly\GAC_64）
• 检查ESP服务本身的运行架构，以及你注册DLL时使用的gacutil版本架构，如果仅注册了其中一个架构的GAC，而ESP服务运行的是另一架构，就会找不到DLL
• 可在应用启动代码中添加日志输出Environment.Is64BitProcess值，对比手动运行与ESP触发运行的结果是否一致

2. 检查模拟用户的配置文件加载状态 #

• ESP使用本地系统账户模拟AD用户运行作业时，默认可能不会加载目标AD用户的配置文件，导致.NET运行时无法读取用户级的程序集绑定配置
• 检查ESP作业配置中是否开启了「加载用户配置文件」的选项，同时可添加日志输出Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)，确认路径是否为目标AD用户的目录，而非本地系统账户的目录

3. 验证工作目录与应用配置文件加载逻辑 #

• ESP触发作业时默认工作目录通常为ESP服务自身的安装目录，而非你的.NET应用所在目录，会导致应用根目录下的app.config无法被正确加载，如果你的应用依赖配置文件中的程序集绑定重定向规则，就会出现版本不匹配的加载错误
• 可添加日志输出Environment.CurrentDirectory，确认与手动运行的工作目录是否一致，两种修复方案：
  • 在ESP作业配置中显式指定工作目录为你的.NET应用所在路径
  • 在应用启动入口处主动设置工作目录，示例代码：

  Environment.CurrentDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
  

4. 捕获程序集绑定日志定位根因 #

直接使用.NET官方工具fuslogvw.exe（程序集绑定日志查看器）捕获绑定失败的详细日志：

• 以管理员身份运行fuslogvw.exe，设置日志记录选项为「记录绑定失败到磁盘」
• 重启ESP服务后触发作业复现问题
• 打开对应失败的绑定日志，可直接看到.NET运行时搜索DLL的路径、期望的版本号、公钥令牌等信息，快速定位是版本不匹配、架构不对还是路径搜索范围问题

5. 排查安全策略限制 #

即使AD账户拥有管理员权限，也可能存在上下文相关的安全策略拦截：

• 检查本地安全策略中的AppLocker规则、软件限制策略，确认是否存在规则禁止服务上下文加载目标DLL（交互式登录的规则与服务上下文规则通常是分开配置的）
• 确认目标DLL的数字签名有效，没有被杀毒软件、EDR等安全工具拦截加载

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