gpt4 book ai didi

c# - 使用 TPL 和进程外 COM 服务器的 C# WPF 应用程序的奇怪问题

转载 作者:太空宇宙 更新时间:2023-11-03 10:46:22 25 4
gpt4 key购买 nike

我长期以来一直是 stackoverflow 的被动用户,发现了很多有用的信息,但这是我在这里的第一个问题。恐怕我的第一个问题有点含糊,因为我没有展示代码,而是描述问题。我不是在寻找直接的解决方案,而是在寻找有关进一步阅读的一些提示,这些提示将使我能够理解我的问题的原因。

我的问题是关于 C# WPF 应用程序 (.NET 4.0),它使用 TPL 对进程外 COM 服务器进行并行调用。进程外 COM 服务器是机械工程中使用的一个相当昂贵的商业应用程序——我们称它为 MechEngApp。 COM 服务器是 64 位可执行文件。我的 C# WPF 应用程序是一个交互式程序,用于自动执行 MechEngApp 中的某些计算。它连接到 MechEngApp,从中读取一些输入,自行进行一些计算并将结果写回 MechEngApp。我们目前正准备切换到新版本的 MechEngApp。虽然在版本 X 中一切正常,但我们在新版本 Y 中遇到了一个奇怪的问题。

我的 C# WPF 应用程序是这样工作的:

  • MechEngApp(进程外 COM 服务器)已经在运行(只有一个实例在运行)
  • 我的 C# WPF 应用程序从主线程连接到调用 Marshal.GetActiveObject("MechEngApp.Application") 的 COM 服务器。该对象贯穿整个程序。
  • 用户以交互方式选择一些输入元素(仍在主 WPF 线程中)
  • 输入完成后,主要计算由后台工作线程执行。
  • 在 backgroundworker 中,我使用 TPL 的 Parallel.For、Parallel.ForEach 或 Parallel.Invoke 在 MechEngApp 中创建一些东西(调用 COM 服务器)

使用 MechEngApp 的当前版本 X,这已经工作多年没有任何问题。在 MechEngApp 的新版本 Y 中,我们在某个配置中遇到了问题:

  1. 如果我的 C# 应用程序构建为 32 位应用程序,我可以通过顺序或并行调用来调用 MechEngApp 的 COM 服务器 - 一切都很好。
  2. 如果我的 C# 应用程序构建为 64 位应用程序,我可以毫无问题地通过顺序调用来调用 MechEngApp 的 COM 服务器。
  3. 如果我的 C# 应用程序构建为 64 位应用程序,并且如果我使用来自 TPL 的并行调用,我会收到类型为 TYPE_E_LIBNOTREGISTERED 的 COMException。

之后我们开始调查,发现 MechEngApp 的 TypeLibs 只有 win32 的注册表项 (HKCR\TypeLib, HKCR\Wow6432Node\TypeLib, HKLM\SOFTWARE\Classes\TypeLib, HKLM\SOFTWARE\Classes\Wow6432Node\类型库)。我们试图将它们复制为 win64 条目,但突然就没有了。 3 也有效。

所以我有一个解决我的问题的方法,但我不明白为什么以及它是如何工作的。这几周看了很多书,增长了进程外COM的使用知识,但还是不能回答一些问题:

A) 对于进程外 COM,混合 32 位和 64 位客户端和服务器并不重要,不是吗?

B) 我读过,对于进程内 COM,ThreadingModel 很重要,但对于进程外,它应该无关紧要。对吧?

C) 注册表中的 win64 TypeLib 条目何时重要?仅当 COM 服务器为 32 位和 64 位客户端提供不同的类型库时?

D) 当 win64 条目存在时,进程间通信有什么不同?为什么我的情况没有。 3 当 win64 条目存在时表现不同?

E) 与 D 相关:为什么将我的 C# 应用构建为 32 位或 64 位程序会影响进程外 COM 服务器的行为?

F) 我们使用多年没有任何问题的 MechEngApp 版本 X 也是一个没有 win64 条目的 64 位应用程序。如果 win64 条目很重要,为什么它在过去起作用?

最佳答案

A) For out-of-process COM mixing 32 and 64 bit clients and servers shouldn't really matter, should it?

COM 会处理这个问题,但拥有匹配的位数总是好的。

B), C), E), F)

见下文。

D) What's the difference in the inter process communication, when the win64 entries exist? Why is my case no. 3 behaving different when the win64 entries exist?

我们不确定第 3 方进程外服务器进程内部发生了什么(例如,它是否使用具有多个线程、单个 STA 线程或多个 STA 线程的 MTA 单元),所以我只能推测。

就是说,我想在您在客户端引入并发之前,内部 MechEngApp COM 服务器进程没有跨线程 COM 编码。一旦你这样做了,你可能还在 MechEngApp 进程中引入了多线程。显然,MechEngApp 依赖于 COM typelib 编码器,当它在自己的线程之间编码 COM 对象时(例如,使用 CoMarshalInterface)。这将是进程内编码,因为它发生在 MechEngApp 进程内。为使其正常工作,必须为 64 位应用程序提供正确的 64 位注册表项。

您可能还可以通过以管理员权限运行 MechEngApp.exe/RegServer 来使其工作。

关于c# - 使用 TPL 和进程外 COM 服务器的 C# WPF 应用程序的奇怪问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23239995/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com