访问 COM 时如何在 x86 和 x64 下编写安全的 C# 代码？典型的陷阱？答案

【问题标题】：How write C# code being safe both under x86 and x64 when accessing COM? Typical traps?访问 COM 时如何在 x86 和 x64 下编写安全的 C# 代码？典型的陷阱？
【发布时间】：2010-03-11 10:35:53
【问题描述】：

我们使用一个用 C# 编写的开源库来包装 Windows BITS COM 组件。但是，代码只能在 x86 模式下安全运行。我想通过使 x86 和 x64 都安全来为该库做出贡献，但是我在这个领域没有深入的知识。

您能否在此处列出好的/坏的做法、典型问题、可能还有原则等，需要注意什么？

例如，我在代码中看到IntPtr 被强制转换为System.Int32，这在x64 上不能很好地运行。您将如何以与平台无关的方式解决此问题和类似问题？

【问题讨论】：

标签： c# .net com x86 64-bit

【解决方案1】：

我认为您在谈论SharpBits.NET，它是 BITS 组件的包装器。是的，有几个地方作者搞砸了互操作。没有其他原因它不能工作，BITS 可用作 32 位和 64 位 COM 服务器。 this thread 就是这样一个错误的例子。

P/Invoke 声明错误或手动封送处理不当是所有 64 位互操作问题的绝大部分。我在this thread 中留下了很多关于 64 位编码问题的提示。

【讨论】：

【解决方案2】：

嗯，你没有；）

说真的。

问题是 64 位和 32 位 com 对象不可互操作，因此您肯定需要一些没有强绑定的延迟加载设置（然后我们不谈论 COM，而是使用 IDispatch 谈论 COM），或者两个不同的 wrapepr 程序集。

整个 x86/x64 是一个巨大的差距 - 因为它很难跨越。例如，你不能将一个 32 位的 DLL 加载到一个 64 位的进程中——不管有没有包装器，你就是不能加载它。

MS 故意以这种方式设计它。因此 - 没有办法解决它。

【讨论】：

Thanx Tom，但我想知道...我们正在讨论 BITS 组件，它是 Windows 的本机部分。因此，如果我运行 Win x64，我假设 BITS COM 组件已经是 64 位实现。所以使用 32 位 .NET 包装器不一定是个好主意。还是我错了？
不确定。说真的 - 即使在 64 位系统上，BITS 也可能只是 32 位 - 如果编译 64 位（不需要内存等）没有意义，您可能会发现它没有 64 位版本。您需要检查文档。请注意，这不是限制 - 例如。 MS 建议网站 (IIS) 应始终运行 32 位，因为它更高效，并且网站很少需要在其应用程序池中使用 64 位内存功能。