如何在64位IIS应用池中兼容使用32位DLL与64位DSN？

这个问题太典型了——64位IIS进程和32位DLL的架构冲突，刚好卡在“启用32位应用池就炸DSN，禁用就炸DLL”的两难境地。别慌，下面给你几个靠谱的解决方案，都是生产环境验证过的：

这个方法是把32位DLL包装成独立的32位COM+进程，让64位IIS应用通过COM远程调用它，同时64位应用本身依然可以用64位DSN连接SQL Server，完美规避架构冲突。步骤如下：

• 首先注册32位DLL：打开管理员身份的命令提示符，运行 %SystemRoot%\SysWOW64\regsvr32.exe "C:\你的路径\32位DLL文件.dll"——必须用SysWOW64目录下的regsvr32，这是32位版本的注册工具，64位的regsvr32没法处理32位DLL。
• 打开组件服务（运行 dcomcnfg 就能打开），展开「组件服务」→「计算机」→「我的电脑」→「COM+应用程序」。
• 右键点击「COM+应用程序」，选「新建」→「应用程序」，跟着向导走：选「创建空应用程序」，给应用起个好记的名字（比如My32BitDLLWrapper），然后选「服务器应用程序」（这会让COM+在独立的32位进程里运行），最后设置应用的身份——最好用有足够权限的账户，比如本地系统或者专门的服务账户。
• 右键点击刚创建的COM+应用，选「新建」→「组件」，向导里选「安装新组件」，找到你刚才注册的32位DLL添加进去。
• 回到COM+应用的属性页，切换到「高级」选项卡，勾选**「启用32位应用程序」**——这一步是核心，确保COM+进程以32位模式运行。
• 现在你的64位IIS应用就可以像调用普通COM组件一样调用这个封装后的DLL了，COM+会自动处理跨进程通信，64位进程和32位COM+进程互不干扰，DSN的架构问题也解决了。

如果你的32位DLL功能复杂，或者需要长时间运行的后台逻辑，可以把它封装成32位Windows服务，然后64位IIS应用通过进程间通信（IPC）和服务交互，比如用WCF、命名管道或者TCP协议。步骤大概是：

• 创建一个x86平台的.NET Windows服务项目（在项目属性里把「平台目标」设为x86），在服务里引用并调用32位DLL，暴露需要的功能接口。
• 给服务添加WCF端点（比如用命名管道），让64位应用能通过WCF客户端调用服务方法。
• 安装并启动这个32位服务（可以用installutil.exe或者Visual Studio的发布工具）。
• 在64位IIS应用里添加WCF客户端，调用32位服务的接口完成功能调用。
  这个方法灵活性极高，你能完全控制32位组件的运行环境，适合需要自定义逻辑的场景。

如果只是临时解决问题，不想配置COM+或者写服务，可以写个简单的32位控制台程序当代理：

• 创建一个x86平台的控制台项目，在里面调用32位DLL的功能，然后通过标准输入输出、共享内存或者消息队列和64位IIS应用通信。
• 64位应用需要调用DLL时，启动这个32位代理进程，传递参数，等代理返回结果后再继续执行。
  这个方法的缺点是要处理进程启动、通信的细节，性能不如前两个，但胜在快速实现，适合测试或者临时场景。

额外注意事项 #

• 不管用哪个方法，都要确保32位DLL的依赖项（比如其他32位辅助DLL）都在正确路径（比如和代理进程/COM+应用同目录，或者在SysWOW64目录）。
• 如果32位DLL是.NET写的，要确保它的目标框架和代理进程/服务的框架版本兼容。

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