问题标签 [rcw]

判断 COM 对象的引用计数是否已达到 0 的一种方法是尝试访问其成员之一并捕获生成的 InvalidComObjectException，这不是很优雅，而且似乎不太适合自己。另一种方法是调用 Marshal.ReleaseComObject 并检查结果，但这需要您将 Com 对象的引用计数减少 1。

有没有直接的方法来告诉？

我正在使用 COM 互操作将托管插件创建到使用 VS2012/.NET 4.5/Win8.1 的非托管应用程序中。所有互操作的东西似乎都正常，但是当我关闭应用程序时，我得到一个 MDA 异常，告诉我在释放 RCW 在完成期间持有的 COM 对象时发生了 AV。

这是调用堆栈：

我的猜测是应用程序已经销毁了它的 COM 对象，其中一些引用被传递给了托管插件 - 并且对 IUnknown::Release 的调用 RCW 使它变得繁荣起来。

我可以在输出窗口 (VS) 中清楚地看到该应用程序已经开始卸载其中的一些 dll。

所以我虽然会管理我自己的生命周期并编写了一个调用 Marshal.ReleaseComObject 的 ComReference 类。这不能正常工作，在阅读后我不得不同意在引用自由传递的场景中调用 Marshal.ReleaseComObject 不是一个好主意。 Marshal.ReleaseComObject 被认为是危险的

所以问题是：有没有办法管理这种情况，以便在退出主机应用程序时不导致 AV？

我有一个非常大的项目，我不能轻易剥离。

关闭应用程序时，我收到错误消息

细节：

不幸的是，我看不到这是关于什么 COM 对象。有人知道我怎么能找到吗？不幸的是，我无法阅读 ASM 来分析反汇编。

我有一个 COM 组件，其中包含 get_XXX 和 put_XXX 方法。我在一个 .NET 项目中使用了它，并为它生成了一个 RCW。我现在看到 get_XXX 和 set_XXX 方法，而不是 put_XXX 方法？这是自动的还是在 IDL 中的某个地方定义的？

我遇到了一个我认为与 CLR 与 COM 对象互操作的方式有关的问题，但我希望这里的一些人可以提供更多的见解。我想为这个问题的模糊性提前道歉，不幸的是我正在与一个有点不透明的系统集成。

考虑以下代码：

COM 互操作类型嵌入在我的程序集中，该程序集由另一个程序作为插件加载。当我第一次创建 的实例时Foo，服务提供者（由程序提供）提供的 COM 对象是非空的。但是，当我立即调用 时Bar()，转换为IComOtherInterface不起作用：该方法打印“true”。

不过，我的问题是，在加载了其他一些插件后，Bar()再次调用会打印"false"。我已经验证它是同一个实例Foo，实际上是同一个实例comObject（我使用调试器用 ID 标记了两者，并且数字没有改变）。所以现在演员阵容成功了。

所以我的问题是：这怎么可能？是否有可能存储的对象comObject实际上是通过同一个 RCW 第二次包装一个新的本机 COM 对象？加载其他程序集是否可能以某种方式改变了的类型标识，IOtherComInterface以便演员现在可以工作？其他一些我实际上无法理解的疯狂可能性？

我正在使用 .NET 的第 3 方 Activex 控件。通过添加对 ActiveX ocx 的引用并将控件拖到我的表单上，我成功地创建了 RCW（AxInterop.ACMELib.dll 和 Interop.ACMELib.dll）。

此时，缺少 RCW 提供的接口，我决定创建自己的组件作为附加包装器。一个原因是我从多个线程访问 RCW，并且我想一次将对 RCW 的访问同步到一个线程。我的课看起来像：

这个类在大多数情况下都能正常工作。但是，有时我的应用程序崩溃而没有我的应用程序可以处理的异常。甚至来自一个包罗万象的未处理异常处理程序。在某些情况下，它实际上确实捕获了“外部组件已引发异常......”，我无法从中恢复。

我以为我已经尝试了一切，直到一时兴起，我在创建它的线程上明确调用了对 RCW 的所有调用，即

我的应用程序不再以这种方式崩溃。我在网上搜索了我的行为的理由，因为当某些东西有效时，我想知道它为什么有效。一无所获，我决定发布这个问题。有人可以告诉我为什么我所做的工作有效，并指导我阅读一些有关此主题的更多信息的文献吗？

在探索 WinRT 时，我对单例进行了实验：通过自己实现 IActivationFactory，我可以“在 ABI 级别”制作单例。工厂每次只返回相同的实例。通过扩展，我的类型对 RoActivateInstance 的任何调用都将返回相同的指针。

奇怪的是，与 .NET 互操作时几乎是透明的：

我对此的解释是，每次实例化都会为 WinRT 对象生成一个新的 RCW。因此，它与单例并不完全相同，但可能足够接近。

我还没有检查过其他语言的预测。

我的意图是将它用于不可变对象，它们甚至可能没有任何构造函数参数。（如果他们这样做，激活工厂将需要保留实例映射。）好处主要是减少了内存占用。

但是我在这里踩危险水域吗？我在 COM/ATL 中看到过类似的结构，但在 WinRT 中呢？

foreach循环调用自动.dispose()实现的对象IDisposable。这是一个不错的功能，但假设您有以下功能：

并且该方法发布了它关联COMWrapper的.dispose()COM 对象。

据我了解，foreach 循环将COMWrapper在循环结束时处理每个循环，但随后离开匹配项COMWrapper，因为它在到达语句结束之前返回。

COMWrapper然而，对于列表中留下的引用来说，这成为一个问题，COMWrapperList因为其中一半的底层 COM 对象 RCW 包装器已被删除，而它们本身并未被处理掉。更糟糕的是，列表的剩余一半完全不受管理的 COM 对象现在漂浮在以太中，并且由于COMWrapper它们存在的对象尚未被处理，因此很难在语句中适当地遍历List和调用（我们不t，毕竟要释放COM Objects两次）。.dispose()finally

是否可以在不捕获异常的情况下确定 COM 对象是否已被释放ObjectDisposedException？有没有更好的方法来处理剩余的 COM 对象及其包装器？或者，也许我完全误读了这种情况，需要重新评估我对 COM 对象的基本理解，我做错了什么？

For certain reasons, I must provide manually written runtime callable wrappers for a number of COM components offered by my shop.

This is the interface definition for component A:

This is the interface definition for component B:

This is the interface definition for component C:

Now, the following test program terminates with an InvalidCastException:

Why would this be?

Edit 1: this is the result of toString() on the exception object:

When I ask Visual Studio to generate runtime callable wrappers for my COM components, it is selecting a strange type to wrap a certain interface property.

This is a summarized type library for component A:

This is the type library for component B:

This is the runtime callable wrapper generated by Visual Studio for component A:

This is the runtime callable wrapper generated by Visual Studio for component B:

Why is Visual Studio selecting the Sts interface instead of the ISts interface to wrap the IStsRsfn.Sts property?