32 位和 64 位应用程序之间的 COM 互操作
我有一个编译为 x86 的 .NET Windows 窗体应用程序 - 它需要编译为 x86，因为它引用了 32 位的第 3 方 DLL。该应用程序使用 COM 互操作来自动化 Office 应用程序和 AutoCAD。我的问题是：我的 COM 互操作代码在 64 位操作系统上对 64 位版本的 Office 和 AutoCAD 是否可以正常工作？我打算尝试一下，但我想知道是否有人知道有什么问题？
I have a .NET windows forms application compiled as x86 – it needs to be compiled as x86 because it references 3rd party DLLs which are 32 bit. The application uses COM interop to automate Office applications and also AutoCAD. My question is: will my COM interop code work okay on a 64 bit operating system against the 64 bit versions of Office and AutoCAD? I’m going to try this out but I wondered whether someone knew of any problems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果 Office 和 AutoCAD 是纯粹的 64 位，那么可能不是，因为它们将是 64 位图像，因此不会加载到 32 位进程中，并且您的 32 位进程会遇到相反的问题。
我们遇到了类似的情况，最终将我们的程序制作为“anycpu”，并提供了另一个 32 位的小程序来与 32 位 dll 进行对话，然后当我们检测到
(intptr.size = 4[32] 或 8[64]) 时如果我们在 64 位机器上，那么我们调用 32 位程序（以执行与这些第 3 方 dll 的通信）并生成某种输出（在我们的例子中，我们编写了一个小的 XML 文件），然后退出。我们等待程序退出，然后读取文件并对响应采取行动。这实际上取决于程序的哪一侧拥有最多的 64/32 和相应的代码。
If the office and autocad are purely 64bit then probably not because they will be 64bit images and therefore not load into a 32bit process and you have the reverse problem for your 32bit ones.
We had a similar situation and ended up making our program "anycpu" and provided another little program that was 32bit to talk to the 32bit dll's then when we detect
(intptr.size = 4[32] or 8[64])if we are on a 64bit machine, then we invoke the 32bit program (to perform the communication to these 3rd party dll's) and generate some kind of output (in our case we wrote a small XML file) and then exit. We waited for the program to exit and then read the file and took action on the responses.It really just comes down to which side of the program has the most 64/32 and code according to that.