混合32位和64位P /调用
我遇到了一个问题，我很确定我知道答案，但我想我至少会问，看看是否有一些“魔法子弹“，这可能会让我非常头疼。混合32位和64位P /调用
以下是高级视图。
我有一个托管的应用程序。此应用程序通过来自不同供应商的第三方库与硬件进行交互。我完全控制了消费的托管应用程序，并对硬件API库进行了零控制。
供应商A仅提供32位原生SDK。为了让我们能够在64位系统上使用它，我们将应用程序标记为以32位模式运行。一切都好。
我们现在正与供应商B集成，供应商B在64位机器上提供64位特定的本机API库。供应商B的32位原生DLL无法在64位系统上工作（试过）。如果我构建以64位或AnyCPU运行的测试工具，则工作正常。如果我将它标记为32位，它会在P/Invoke调用中失败。
似乎供应商A和供应商B硬件将在64位个人电脑上互相排斥，但我想知道是否有人对如何解决这个问题有什么建议。
问题不在于.NET或P/Invoke。这是一个操作系统问题。一个64位进程只能加载64位DLL。一个32位进程只能加载32位DLL。允许32位应用程序在64位Windows上运行的神奇的Windows-on-Windows（或WoW）层存在于用户模式进程（EXE和DLL）与内核之间。没有办法在64位进程中运行32位DLL。 WoW层位于下方。 （基本上WoW是64位Win32 API的32位包装器，它封装了32位世界的进程和操作系统的64位世界之间的数据和函数调用。）
你最好的/唯一的选择是在单独的进程中运行32位和64位组件，并使用某种形式的IPC进行通信。这有助于将核心应用程序与潜在不稳定的第三方组件解耦。如果第三方组件崩溃或行为不当，则只需重新启动包含该组件的进程即可。
您可以制作一个单独的32位进程与供应商A进行交互，然后使用WCF与其进行通信。
是的，我试图避免这种情况 - 但它可能是唯一的办法。 – ctacke 2010-12-08 22:38:42
希望有人可以提出一个更好的选择，但也许你可以在一个单独的进程中打包其中一个库（带宽最低的连接到你的应用程序），然后与它通信（例如通过套接字）。
由于无法将32位和64位图像加载到同一进程中，因此必须使用多进程解决方案。
我们已经在anotehr AppDomain中将其隔离，所以安全性很好。将它移动到anotehr进程会增加我们希望避免的界面复杂性，但似乎是要么放弃供应商A的硬件。 – ctacke 2010-12-08 23:03:07