COM DLL依赖项中的多个进程和静态DLL数据的副本

Question

我希望了解COM DLL运行中的某些意外行为，其中似乎在多个进程之间共享了静态C ++数据。 环境有点复杂，我对各种COM线程模型的理解还很薄弱，我希望有人可以提供帮助。

环境

• 运行多个C＃Web服务的64位操作系统上的IIS服务器，每个服务都在其自己的32位应用程序池中，因此可以处理
  • 池具有“启用32位应用程序” = True设置
• 每个32位C＃服务调用一个不同的进程内32位COM DLL（因此，服务A调用COM DLL 1，服务C调用COM DLL2。这些COM DLL是使用Qt 4.8 ActiveQt用C ++编写的
• COM DLL依赖于共享的32位C ++ DLL数量，即COM DLL 1和2都依赖于Utilities.dll。
• 据我所知，没有为COM DLL设置ThreadingModel，所以我希望系统会回落到主STA上。
  • 我知道这是不满意的，但是我目前没有足够的知识来更改它。
• Utilities.dll包含一些静态C ++数据
• COM DLL是使用“ regsvr32”注册的，尽管我对后者的了解很少，但似乎未在“组件服务”中列出。

观察到的问题是，Utilities.dll中的静态数据似乎最终在不同的IIS进程之间共享，从而产生了不良后果。 我曾预料到，由于COM位于主STA中，因此它们将被访问，就好像它不是线程安全的一样，每个进程将获得自己的DLL静态数据副本，但是事实并非如此。

有人可以解释静态数据最终如何在进程之间共享吗？

如何避免这种情况？ （除了重构代码以删除所有静态数据外，当前尚不可行）

Answer 1

如果看到COM对象之间共享的数据，则意味着它们托管在同一进程中。 是的，可以在进程之间共享数据，但并非偶然。 由于您的应用程序池是不同的进程，因此必须将这些COM对象托管在进程外，并且只是将存根加载到应用程序池中。

如果您可以控制Utilities.dll（听起来像您一样），那么我将尝试添加一些调试信息，以查找承载COM对象的进程ID。 我希望您会发现它与应用程序池ID不匹配，并且您将能够使用该ID找出正在发生的事情。

理想情况下，设计良好的COM对象位于何处都应该无关紧要，这应该是实现细节。 是否可以取消共享数据结构？