wcf - 垃圾回收后 WCF 中的访问冲突与 COM 对象

Question

我有一个自托管的 WCF 应用程序，其中服务对象（每次调用，单个并发）使用构建在名为 Clarion 的平台上的嵌入式 COM 对象（在整个调用过程中从类中引用）。COM 实例与服务对象一起创建和销毁。然而，他们在下面访问一个需要很长时间来初始化的单例存储库（非常类似于：Startup Code for Loading COM Object for WCF Service）。所以第一次通话很长。因此，我必须在启动时调用它。

如果我在启动时不实例化 COM 对象，一切都很好（除了第一次调用很长）。但是如果我这样做了，在垃圾收集之后，下一个请求将在尝试访问 COM 时因访问冲突异常而崩溃。

服务对象实现IDisposable了所有 COM 对象都使用Marshal.ReleaseComObject. 启动调用还释放 COM 对象。

我的猜测是启动 COM 以某种方式被重用或回收。我不想要它！我能确保它永远死去吗？或者如果不可能，我可以将其标记为不用于垃圾收集吗？显然，GC.KeepAlive这里是无关紧要的，因为这些是不同方法中的不同线程。

更多细节：COM 对象最近支持 MTA。它们是线程安全的和完全并发的，但是在之前，当它们只是 STA 时，没有这样的问题。此外，当这些人在单独的线程中运行时，在 WCF 之外不会发生任何不好的事情。

Answer 1

好的。看来我在上

它是血腥隐藏的单例对象，或者更确切地说，是编写 COM 的平台的运行时库（SoftVelocity Clarion）。当启动 COM 被杀死时，它由于某种原因被释放，可能是因为引用计数下降，是时候卸载 DLL 本身了。虽然当我调整时DllCanUnloadNow，它没有帮助，但我会弄清楚它来自哪里。

编辑： Clarion 对 COM 对象的支持并不简单。由模板生成的代码执行数据库字典（DctInit和DctKill分别）和主程序中一些特定类的分配和释放，当主线程结束时结束。然而，在 MTA COM 对象中，主线程的结束并不意味着程序的结束。因此，最简单的解决方案是嵌入代码以防止执行DctKill.

另外，不要忘记调用AttachThreadToClarion(TRUE).Destruct 方法，因为垃圾收集线程会有所不同。

此问题可能会在广泛使用运行时或全局对象的老一代 IDE 中出现。谨防。