从 32 位应用程序通过 COM 调用 x64 程序集答案

【问题标题】：Calling an x64 assembly via COM from a 32 bit App从 32 位应用程序通过 COM 调用 x64 程序集
【发布时间】：2012-01-01 21:24:39
【问题描述】：

简短的问题：这可能吗（当然是在 x64 操作系统上）？如果不是，为什么？

我为 excel 32 开发了一个 c# 插件 dll。

在 x86 中编译时可以正常工作。

在 x64 中编译时，COM 调用失败。

我需要 64 位版本的 excel 吗？

我认为 COM 与编译架构无关，并且可以在以不同技术开发并具有不同架构的 dll 之间进行通信，但我认为后者是错误的。

我猜 x64 位 dll 显然不能通过 COM（或其他）从 32 位应用程序调用。

【问题讨论】：

你可能需要一个 64 位系统（至少是内核）来运行 64 位代码。
@BasileStarynkevitch 当然可以。我在帖子中添加了精度
您是否已经尝试为 AnyCPU 编译？
@Filburt 是的，我做到了。但深入挖掘让我意识到这不是问题所在。

标签： c# .net com .net-assembly

【解决方案1】：

COM 支持两种服务器，进程内和进程外。 Office 扩展是进程内组件，即加载到进程中的 DLL。 32 位进程的硬性规则是它们不能加载 64 位 DLL。反之亦然。这是由注册表本身强制执行的，32 位进程不能直接访问 64 位 COM 服务器的注册信息。它们被重定向到 HKLM/Software/Wow6432Node 键。或者换句话说，他们甚至无法看到错误位数的组成部分。

进程外组件没有这个限制，它们在自己的进程中运行。 COM 使用 RPC 编组两个进程之间的调用，并记录位数差异。这也是让进程内 64 位服务器与 32 位主机一起工作的一种方法，您可以在代理进程中运行组件。这很难开始，而且几乎不值得麻烦，由于所需的编组和上下文切换，进程外调用比进程内调用要多昂贵。不仅稍微贵一点，而且慢了大约 10,000 倍，主要是因为进程内函数调用非常快。它仅用于使旧式 32 位服务器与 64 位程序一起工作。想试试看COM+托管，我也不是很了解。

【讨论】：

非常感谢，伙计。这正是我正在寻找的那种干净的确认。并且您关于进程外调用的精确性对我们来说非常宝贵，它使我们节省了尝试以糟糕的性能结果来做这件事的时间。所以如果我真的想坚持我的 x64 框架，我想我需要一个 x64 分布的 Excel。