包装 DirectSound 接口的托管类应该是 IDisposable 吗？
我正在围绕 DirectSound 编写一个托管包装器。 （这是一个简单的部分包装器，仅解决我的特定问题。不要告诉我有关 NAudio 或其他任何内容。）包装 IDirectSound8 的托管类应该是 IDisposable 吗？为什么？关于 IDirectSoundBuffer8 的同样问题。
I'm writing a managed wrapper around DirectSound. (It's a simple partial wrapper that solves my specific problem and nothing more. Don't tell me about NAudio or whatever.) Should a managed class that wraps IDirectSound8 be IDisposable and why? Same question about IDirectSoundBuffer8.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从技术上来说：是的。实际上：不。 IDirectSound8 是一个 COM 接口，它们通过互操作库非常方便地封装在 .NET 中。一个RCW。 RCW 管理底层 COM coclass 对象的引用计数。 RCW不实现IDisposable，尽管它很大程度上依赖于非托管资源。
之所以没有这样做，是因为几乎不可能正确实现 IDisposable。 COM 组件类实现多个接口，创建一个接口会增加引用计数。在处置是安全的之前，您必须 100% 确定所有这些接口指针都不再使用。这很难做到，这些指针是以意想不到的方式创建的。就像使用接口之一的索引属性一样，中间接口指针在代码中永远不可见。
这不是一个真正的问题，垃圾收集器负责引用计数，终结器完成工作。只不过对象释放的时间稍微长一些而已。标准 GC 行为。不幸的是，进程外 COM 服务器具有明显的副作用，当代码停止使用接口时，进程没有从 TaskMgr 进程列表中消失，程序员往往会感到恼火。这里和论坛上有很多很多“Excel/Word 无法退出”的问题。
如果您无论如何都想实现它，那么您可以通过在 Dispose() 实现中调用 Marshal.FinalReleaseComObject() 来实现。只是要注意失败的风险显着增加，错误的调用会导致很难诊断失败。与在本机代码中删除对象但仍然有指向它的指针没什么不同。如果它实际上是一个必须立即释放的“重”对象，那么 GC.Collect() + GC.WaitForPendingFinalizers() 也可以完成工作，并且出错的风险要小得多。当然有副作用。
Technically: yes. Practically: no. IDirectSound8 is a COM interface, they are very conveniently wrapped in .NET with a interop library. An RCW. That RCW manages the reference counts on the underlying COM coclass object. An RCW does not implement IDisposable, even though it very much hangs on to an unmanaged resource.
The reason it doesn't is because it is almost impossible to implement IDisposable correctly. A COM coclass implements multiple interfaces, creating one adds to the reference count. You would have to be 100% sure that all of those interface pointers are no longer in use before a dispose would be safe. That's very hard to do, those pointers get created in unexpected ways. Like using an indexed property of one of the interfaces, the intermediate interface pointer is never visible in your code.
This is not a real problem, the garbage collector takes care of the reference counts, the finalizer gets the job done. It is just that it takes a bit longer for the object to be released. Standard GC behavior. Unfortunately out-of-process COM servers have observable side-effects, programmers tend to get annoyed when the process doesn't disappear from the TaskMgr processes list at the instant their code stops using the interfaces. Many, many "Excel/Word doesn't quit" questions here and at the forums.
If you want to implement it anyway then you can do so by calling Marshal.FinalReleaseComObject() in your Dispose() implementation. Just beware of the significantly increased risk for failure, getting that call wrong produces very hard to diagnose failure. Not quite unlike deleting an object in native code and still having a pointer to it. If it is actually a "heavy" object that must be released instantly then GC.Collect() + GC.WaitForPendingFinalizers() gets the job done too with much less risk of getting it wrong. With side-effects of course.