WCF服务中使用DinkToPDF遇BadImageFormatException等异常求助

我之前也踩过类似的WCF + DinkToPDF的坑，结合你描述的情况——控制台正常但WCF里报错，大概率是IIS运行架构、项目编译设置、wkhtmltopdf dll位数三者不匹配导致的，给你几个具体的排查和解决步骤：

1. 统一项目编译平台目标 #

右键你的WCF项目 → 属性 → 生成 → 目标平台，一定要和你使用的wkhtmltopdf dll位数完全一致：

• 用64位dll就选x64
• 用32位dll就选x86
• 别选Any CPU，因为这个选项在IIS环境下会根据应用池设置自动切换架构，很容易出现不匹配的情况。

2. 配置IIS应用池的架构设置 #

打开IIS管理器，找到你的WCF服务对应的应用池 → 高级设置：

• 找到「启用32位应用程序」选项：
  • 如果用64位dll，把这个选项设为False
  • 如果用32位dll，设为True
• 修改完成后重启应用池，再测试调用BasicConverter.Convert()方法。

3. 解决32位dll的PInvoke栈不平衡问题 #

你提到用32位dll时出现栈不平衡报错，这通常是因为编译平台和应用池架构不统一导致PInvoke调用签名错位。先完成上面两步的架构统一后，这个问题大概率会自动消失。
如果还是报错，可以尝试升级DinkToPDF的NuGet包到最新稳定版，旧版本的库在32位环境下的PInvoke签名可能存在兼容性问题。

4. 确保wkhtmltopdf dll的正确部署 #

• 把对应位数的wkhtmltopdf dll放在解决方案根目录，同时设置dll的属性为「复制到输出目录：始终复制」，这样编译时会自动将dll拷贝到项目的输出文件夹（比如bin\Debug\x64），避免IIS加载错误的版本或者找不到dll。
• 部署到服务器时，也要确保服务器上的WCF服务目录里有对应位数的dll。

5. 额外排查点 #

• 检查IIS应用程序池的身份是否有足够权限访问wkhtmltopdf dll所在的目录，权限不足也可能导致加载失败（不过你的报错更偏向架构问题，但可以排除一下）。
• 如果是部署到远程服务器，确认服务器操作系统的位数（现在大多是64位），确保和你的dll位数匹配。

内容的提问来源于stack exchange，提问作者S-Vuk