如何在Release（）上处理NET COM互操作对象
[英]How to dispose of a NET COM interop object on Release()
问题描述
我有一个用托管代码（C ++ / CLI）编写的COM对象。 我在标准C ++中使用该对象。
当COM对象被释放时，如何强制立即调用COM对象的析构函数？ 如果那是不可能的，请调用我有Release（）调用我的COM对象上的MyDispose（）方法？
我的代码声明对象（C ++ / CLI）：
[Guid("57ED5388-blahblah")]
[InterfaceType(ComInterfaceType::InterfaceIsIDispatch)]
[ComVisible(true)]
public interface class IFoo
{
void Doit();
};
[Guid("417E5293-blahblah")]
[ClassInterface(ClassInterfaceType::None)]
[ComVisible(true)]
public ref class Foo : IFoo
{
public:
void MyDispose();
~Foo() {MyDispose();} // This is never called
!Foo() {MyDispose();} // This is called by the garbage collector.
virtual ULONG Release() {MyDispose();} // This is never called
virtual void Doit();
};
我使用该对象的代码（本机C ++）：
#import "..\\Debug\\Foo.tlb" ... Bar::IFoo setup(__uuidof(Bar::Foo)); // This object comes from the .tlb. setup.Doit(); setup->Release(); // explicit release, not really necessary since Bar::IFoo's destructor will call Release().
如果我在我的COM对象上放置析构函数方法，则永远不会调用它。 如果我放置一个终结器方法，它会在垃圾收集器到达时调用它。 如果我明确调用我的Release（）覆盖，则永远不会调用它。
我真的很喜欢它，所以当我的原生Bar :: IFoo对象超出范围时，它会自动调用我的.NET对象的dispose代码。 我想我可以通过覆盖Release（）来实现它，如果对象count = 0则调用MyDispose（）。 但显然我没有正确地覆盖Release（）因为我的Release（）方法从未被调用过。
显然，我可以通过在接口中放置MyDispose（）方法并要求使用我的对象的人在Release（）之前调用MyDispose（）来实现这一点，但是如果Release（）只是清理了对象，它会更加流畅。
是否有可能在释放COM对象时立即强制调用.NET COM对象的析构函数或其他方法？
谷歌搜索这个问题让我有很多命中，告诉我调用System.Runtime.InteropServices.Marshal.ReleaseComObject（），当然，这就是告诉.NET释放COM对象的方法。 我想要COM Release（）来处理.NET对象。
6 个解决方案
解决方案1
11 2010-12-21 10:11:02
我有一个用托管代码（C ++ / CLI）编写的COM对象。 我在标准C ++中使用该对象。 当COM对象被释放时，如何强制立即调用COM对象的析构函数？ 如果那是不可能的，我可以让Release（）在我的（托管的DotNet - GBG）COM对象上调用Dispose（）（而不是MyDispose（） - GBG）方法吗？
RE：当客户端是非托管代码时，强制确定性释放由DotNet COM Server绑定的资源。 这些资源可以安排在垃圾收集器收集项目时释放，但这不是确定性的，并且对于垃圾收集不频繁的大型内存系统，文件流等资源可能无法释放数小时或数天。
这是COM Callable Wrappers（CCW）的一个常见问题，可以通过另一个有点相关的线程看到： 是否可以拦截（或意识到）COM引用计数暴露给COM的CLR对象 。 在这种情况下，无论是在编写自己的COM客户端的任何情况下，无论是在托管代码还是非托管代码下，只需通过调用IDisposable.Dispose（）方法就可以轻松解决。 但是，该方法不适用于（例如）一个DotNet COM编解码器类，其客户端可能是操作系统本身，哪个客户端不应该知道COM服务器是非托管或托管的（DotNet）。
可以根据MSDN链接在DotNet COM服务器上实现IDisposable.Dispose（）模式： http ： //msdn.microsoft.com/en-us/library/system.idisposable.aspx ，但这不会做任何事情很好，因为CCW会永远不会调用Dispose（）方法。 理想情况下，mscoree.dll中CCW的实现应该真正检查并调用IDisposable.Dispose（）方法，如果实现为CCW发布和/或终结/析构函数的一部分。 我不确定为什么微软没有这样做，因为他们可以轻松确定DotNet COM类是否支持IDisposable，并且如果它在最终版本上调用Dispose（），那么他们可以轻松确定大会信息，因为这样就可以了CCW，可以避免由于额外的接口参考而导致处理引用计数的所有复杂性。
我无法看到这将如何“破坏”任何现有代码，因为IDisposable知道的任何客户端仍然可以调用Dispose（），如果根据上述模板实现，则只能在第一次调用时有效地执行任何操作。 微软可能会担心一个类被废弃，而仍有托管的引用，它不会知道它被处置，直到开始尝试使用已经处置的资源抛出异常，但这是任何不当的潜在问题使用IDisposable接口，即使只有DotNet客户端：如果有多个对同一对象实例的引用，并且其中任何一个都调用Dispose（），则其他人会发现尝试使用所需的已处置资源导致异常。 对于这种情况，应该总是使用处理布尔值（根据IDisposable模板模板）放入警卫，或者仅通过公共包装器引用对象。
由于Microsoft在mscoree.dll的CCW实现中没有完成所需的几行代码，我在mscoree.dll周围编写了一个包装器，增加了这个额外的功能。 它有点复杂，为了控制任何DotNet COM类的任何实例的包装器的创建，我还需要包装IClassFactory接口并在我的“CCW_Wrapper”包装器类中聚合CCW实例。 此包装器还支持来自另一个外部类的更多聚合级别。 该代码还引用了正在使用的mscoree.dll实现中的类实例的计数，以便在没有引用时能够在mscoree.dll上调用FreeLibrary（如果有必要，可以在以后再次调用LoadLibrary）。 代码也应该是多线程友好的，因为Windows 7下的COM需要。我的C ++代码如下：
2010年12月22日编辑：消除了COM_Wrapper构造函数的一个不必要参数：
#include <windows.h>
HMODULE g_WrappedDLLInstance = NULL;
ULONG g_ObjectInstanceRefCnt = 0;
//the following is the C++ definition of the IDisposable interface
//using the GUID as per the managed definition, which never changes across
//DotNet versions as it represents a hash of the definition and its
//namespace, none of which can change by definition.
MIDL_INTERFACE("805D7A98-D4AF-3F0F-967F-E5CF45312D2C")
IDisposable : public IDispatch {
public:
virtual VOID STDMETHODCALLTYPE Dispose() = 0;
};
class CCW_Wrapper : public IUnknown {
public:
// constructor and destructor
CCW_Wrapper(
__in IClassFactory *pClassFactory,
__in IUnknown *pUnkOuter) :
iWrappedIUnknown(nullptr),
iOuterIUnknown(pUnkOuter),
iWrappedIDisposable(nullptr),
ready(FALSE),
refcnt(0) {
InterlockedIncrement(&g_ObjectInstanceRefCnt);
if (!this->iOuterIUnknown)
this->iOuterIUnknown = static_cast<IUnknown*>(this);
pClassFactory->CreateInstance(
this->iOuterIUnknown,
IID_IUnknown,
(LPVOID*)&this->iWrappedIUnknown);
if (this->iWrappedIUnknown) {
if (SUCCEEDED(this->iWrappedIUnknown->QueryInterface(__uuidof(IDisposable), (LPVOID*)&this->iWrappedIDisposable)))
this->iOuterIUnknown->Release(); //to clear the reference count caused by the above.
}
this->ready = TRUE; //enable destruction of the object when release decrements to zero.
//OUTER IUNKNOWN OBJECTS MUST ALSO PROTECT THEIR DESTRUCTORS IN SIMILAR MANNERS!!!!!
}
~CCW_Wrapper() {
this->ready = FALSE; //protect from re-entering this destructor when object released to zero.
if (this->iWrappedIDisposable) {
//the whole reason for this project!!!!!!!!
this->iWrappedIDisposable->Dispose();
//the following may be redundant, but to be sure...
this->iOuterIUnknown->AddRef();
this->iWrappedIDisposable->Release();
}
if (this->iWrappedIUnknown)
this->iWrappedIUnknown->Release();
if (!InterlockedDecrement(&g_ObjectInstanceRefCnt)) {
//clear all global resources including the mutex, multithreading safe...
HMODULE m = (HMODULE)InterlockedExchangePointer((PVOID*)&g_WrappedDLLInstance, (LPVOID)0);
if (m)
FreeLibrary(m);
}
}
// IUnknown Interface
STDMETHOD(QueryInterface)(REFIID riid, void **ppv) {
if (ppv) {
*ppv = nullptr;
if (riid == IID_IUnknown) {
*ppv = static_cast<IUnknown*>(this);
this->AddRef();
return S_OK;
}
else if (this->iWrappedIUnknown) {
return this->iWrappedIUnknown->QueryInterface(riid, ppv);
}
return E_NOINTERFACE;
}
return E_INVALIDARG;
}
STDMETHOD_(ULONG, AddRef)() {
return InterlockedIncrement(&this->refcnt);
}
STDMETHOD_(ULONG, Release)() {
if (InterlockedDecrement(&this->refcnt))
return this->refcnt;
if (this->ready) //if not being constructed or destructed...
delete this;
return 0;
}
private:
IUnknown *iOuterIUnknown;
IUnknown *iWrappedIUnknown;
IDisposable *iWrappedIDisposable;
BOOL ready;
ULONG refcnt;
};
class ClassFactoryWrapper : public IClassFactory {
public:
// constructor and destructor
ClassFactoryWrapper(IClassFactory *icf) : wrappedFactory(icf), refcnt(0), lockcnt(0) {
InterlockedIncrement(&g_ObjectInstanceRefCnt);
}
~ClassFactoryWrapper() {
if (wrappedFactory)
wrappedFactory->Release();
if (!InterlockedDecrement(&g_ObjectInstanceRefCnt)) {
//clear all global resources, multithreading safe...
HMODULE m = (HMODULE)InterlockedExchangePointer((PVOID*)&g_WrappedDLLInstance, (LPVOID)0);
if (m)
FreeLibrary(m);
}
}
// IUnknown Interface
STDMETHOD(QueryInterface)(REFIID riid, void **ppv) {
if (ppv) {
*ppv = nullptr;
if (riid == IID_IUnknown) {
*ppv = static_cast<IUnknown*>(this);
this->AddRef();
}
else if (riid == IID_IClassFactory) {
*ppv = static_cast<IClassFactory*>(this);
this->AddRef();
}
else {
return E_NOINTERFACE;
}
return S_OK;
}
return E_INVALIDARG;
}
STDMETHOD_(ULONG, AddRef)() {
return InterlockedIncrement(&this->refcnt);
}
STDMETHOD_(ULONG, Release)() {
if (InterlockedDecrement(&this->refcnt) || this->lockcnt)
return this->refcnt;
delete this;
return 0;
}
// IClassFactory Interface
STDMETHOD(CreateInstance)(IUnknown *pUnkOuter, REFIID riid, void **ppv) {
HRESULT result = E_INVALIDARG;
if (ppv) {
*ppv = nullptr;
if (pUnkOuter && (riid != IID_IUnknown))
return result;
CCW_Wrapper *oipm = new CCW_Wrapper(wrappedFactory, pUnkOuter);
if (!oipm)
return E_OUTOFMEMORY;
if (FAILED(result = oipm->QueryInterface(riid, ppv)))
delete oipm;
}
return result;
}
STDMETHOD(LockServer)(BOOL fLock) {
if (fLock)
InterlockedIncrement(&this->lockcnt);
else {
if (!InterlockedDecrement(&this->lockcnt) && !this->refcnt)
delete this;
}
return wrappedFactory->LockServer(fLock);
}
private:
IClassFactory *wrappedFactory;
ULONG refcnt;
ULONG lockcnt;
};
STDAPI DllGetClassObject(__in REFCLSID rclsid, __in REFIID riid, __deref_out LPVOID FAR* ppv) {
HRESULT result = E_INVALIDARG;
if (ppv) {
*ppv = nullptr;
if ((riid != IID_IUnknown) && (riid != IID_IClassFactory))
return E_NOINTERFACE;
HMODULE hDLL = LoadLibrary(L"mscoree.dll");
if (!hDLL)
return E_UNEXPECTED;
typedef HRESULT (__stdcall *pDllGetClassObject) (__in REFCLSID, __in REFIID, __out LPVOID *);
pDllGetClassObject DllGetClassObject = (pDllGetClassObject)GetProcAddress(hDLL, "DllGetClassObject");
if (!DllGetClassObject) {
FreeLibrary(hDLL);
return E_UNEXPECTED;
}
IClassFactory *icf = nullptr;
if (FAILED(result = (DllGetClassObject)(rclsid, IID_IClassFactory, (LPVOID*)&icf))) {
FreeLibrary(hDLL);
return result;
}
ClassFactoryWrapper *cfw = new ClassFactoryWrapper(icf);
if (!cfw) {
icf->Release();
FreeLibrary(hDLL);
return E_OUTOFMEMORY;
}
//record the HMODULE instance in global variable for freeing later, multithreaded safe...
hDLL = (HMODULE)InterlockedExchangePointer((PVOID*)&g_WrappedDLLInstance, (LPVOID)hDLL);
if (hDLL)
FreeLibrary(hDLL);
if (FAILED(result = cfw->QueryInterface(IID_IClassFactory, ppv)))
delete cfw; //will automatically free library and the held class factory reference if necessary.
}
return result;
}
extern "C"
HRESULT __stdcall DllCanUnloadNow(void) {
if (g_ObjectInstanceRefCnt)
return S_FALSE;
return S_OK;
}
extern "C"
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved ) {
switch (ul_reason_for_call) {
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
DLL还需要'.def'文件，如下所示：
LIBRARY mscoreeCOM_DisposeWrapper
EXPORTS
DllCanUnloadNow PRIVATE
DllGetClassObject PRIVATE
要使用此源代码，将其编译为DLL并将DLL安装到Windows SYSTEM文件夹中，然后让您的安装程序或您的DotNet COM服务器中的[COMRegisterFunction]方法将InprocServer32的类注册表项从mscoree.dll修改为这个包装器的名称（比如mscoreeWrapper.dll）。 它可以在32位和/或64位下编译，对于在64位系统上安装，应该将64位版本放入System文件夹，将32位版本放入SysWOW64文件夹; 此外，正常的CLSID注册和虚拟化的WOW6432版本都应该修改为InprocServer32条目。 某些应用程序可能需要对此包装器DLL进行数字签名才能无缝工作，这是另一个主题。 如果有人想要，我会在这里找到这些DLL的编译版本的链接。
正如我所说，所需的几行（不包括包装器要求）技术应该真正合并到mscoree.dll中。 有谁知道如何联系微软内部相关部门的某人来提出这个建议？
EDITADD：我已经向Microsoft Connect提交了DotNet Framework的建议 。 这似乎是提供Microsoft反馈的最佳方式。
EDITADD2：在实现此问题的解决方法时，我意识到为什么MIcrosoft可能不会实现这个“自动调用Dispose，如果支持，当CCW引用计数降至零”时。 在编写变通方法时，我必须获取一个指向托管对象上COM接口的引用指针，以便将其传递给纯粹的非托管COM方法，然后必须释放引用计数的Release（）以便不强制使用CCW引用该对象，从而导致内存泄漏，因为它永远不可用于垃圾回收。 我之所以这样做是因为我知道在托管对象上将引用计数减少到零目前只会使CCW删除对该对象的强引用，如果没有其他引用则使其符合垃圾回收的条件。 但是，如果Microsoft按照我的建议实现了Auto Dispose修补程序，或者如果此代码包含mscoree.dll功能，则会在不需要时触发托管对象上的Dispose（）。 对于这种特殊情况，我可以“保护”Dispose（bool disposing）虚方法以防止Dispose（）发生， 但对于任何使用此行为的现有代码都采用相同的假设，包括Microsoft的DotNet Runtime Libraries的实现，实现CCW上的这个“修复”会破坏现有的代码 。 这个包装修复程序仍然适用于自己编写的COM服务器，并且知道这种副作用，因为它们可以在Dispose（）上放置“警卫”。
EDITADD 3：在进一步的工作中，我看到我对Microsoft的建议仍然有效，可以通过在实现的对象实例上调用IDisposable.Dispose（）方法的修复来避免“打破”现有代码的问题。管理COM服务器，如果仅当新的自定义属性（如[AutoComDispose（true）]（默认值为false）应用于托管COM服务器类时，该接口才存在。 通过这种方式，程序员可以选择实现该功能，并且新属性的文档会提醒其使用有关必须“保护”Dispose（）方法，例如当有可能存在“人工引用计数”时Marshal.Release（）方法由托管服务器使用的代码显式调用，或者通过调用Marshal.GetObjectForIUnknown（）等方法隐式调用，在某些情况下，如果ComObject是托管的，则可以调用QueryInterface和Release参考点宾语。
如上所述，本答案的主要问题是安装使用的复杂性。
解决方案2
3 已采纳 2009-11-12 20:51:27
实际上，当最后一个引用被释放时，不会从COM客户端调用Dispose（或者我应该说~Foo）而不是Release。 它根本没有实现。 这里有一些想法可以做到这一点。
http://blogs.msdn.com/oldnewthing/archive/2007/04/24/2252261.aspx#2269675
但即使是作者也不建议这种方法。
如果您实现COM客户端，最好的选择是查询IDisposable并显式调用Dispose，iid请求是：
{805D7A98-D4AF-3F0F-967F-E5CF45312D2C}
我能想到的其他选择是实现某种自己的“COM垃圾收集器”。 COM创建的每个对象都将放在一个列表中（假设您的类型的对象只能由COM创建 - 我想不出任何方法可以区别于创建对象的位置）。 然后你必须定期检查列表，并在每个对象上调用如下内容：
IntPtr iUnk = Marshal.GetIUnknownForObject(@object);
int refCount = Marshal.Release(iUnk);
if (refCount == 0)
@object.Dispose();
但这是一个疯狂的想法。
解决方案3
1 2010-12-27 13:08:56
声明为VS 2010（GBG）更正的对象（C ++ / CLI）的代码：
using namespace System;
using namespace System::Runtime::InteropServices;
namespace Bar {
[Guid("57ED5388-blahblah")]
[InterfaceType(ComInterfaceType::InterfaceIsIDispatch)]
[ComVisible(true)]
public interface class IFoo
{
void Doit();
};
[Guid("417E5293-blahblah")]
[ClassInterface(ClassInterfaceType::None)]
[ComVisible(true)]
public ref class Foo : IFoo
{
//these don't need to be seen...
private:
void DisposeManaged() {};
void DisposeUnmanaged() {};
~Foo() {DisposeManaged(); this->!Foo();} // Only called by Dispose() on object instance or direct call and delete in C++/CLI
!Foo() {DisposeUnmanaged();} // Called by the garbage collector and by the above.
public:
//THE FOLLOWING IS WRONG, ONE CANNOT OVERRIDE THE HIDDEN IUNKNOWN RELEASE() METHOD IN THIS WAY!!!
// virtual ULONG Release() {MyDispose(); return 0;} // This is never called automatically!!!
[PreserveSig];
virtual void Doit() {};
};
}
代码更正如下：
Release方法不会覆盖CLI编译器一无所知的隐藏IUnknown :: Release（）方法，如果它被更正为实际返回ULONG值，
建议~Foo（）析构函数只调用！Foo（）终结器，以避免重复它需要做的事情，即释放非托管资源，
析构函数~Foo（）应该处理托管和非托管资源，但是终结器！Foo（）应该只处理这里实现的非托管资源，
除了实现的接口方法之外，不需要公开任何方法
所有接口方法都应该[PreserveSig]以实现与COM的最大兼容性。
使用对象（本机C ++）的代码已针对VS 2010（GBG）进行了更正，更正的注释如下所示（ 请注意，这包含了在编写COM客户端时问题的答案！ ）：
#import "..\\Bar\\Bar.tlb" //raw_interfaces_only
//C++ definition of the managed IDisposable interface...
MIDL_INTERFACE("805D7A98-D4AF-3F0F-967F-E5CF45312D2C")
IDisposable : public IDispatch
{
public:
virtual VOID STDMETHODCALLTYPE Dispose() = 0;
}
...
CoInitialize(NULL);
...
//the syntax for a "Smart Pointer" is as follows:
Bar::IFooPtr pif(__uuidof(Bar::Foo)); // This object comes from the .tlb.
if (pif)
{
//This is not stack based so the calling syntax for an object instance is as follows:
pif->Doit();
//THE FOLLOWING ANSWERS THE QUESTION: HOW TO DISPOSE ON RELEASE: when one controls the COM client!!!
IDisposable *id = nullptr;
if (SUCCEEDED(pif->QueryInterface(__uuidof(IDisposable), (LPVOID*)&id)) && id)
{
id->Dispose();
id->Release();
}
//The Release on the IUnknown is absolutely necessary, as without it the reference count stays as one!
//This would result in a memory leak, as the Bar::Foo's destructor is never called,
//and knows nothing about the IUnknown::Release() even if it were!!!
pif->Release(); // explicit release, not really necessary since Bar::IFoo's destructor will call Release().
}
...
CoUninitialize();
...
似乎问题揭幕者并不真正理解COM服务器的Release引用计数方法与托管代码中引用计数的绝对缺失之间的关系，而不是CCW模拟的：
如果我在我的COM对象上放置析构函数方法，则永远不会调用它。 如果我放置一个终结器方法，它会在垃圾收集器到达时调用它。 如果我明确调用我的Release（）覆盖，则永远不会调用它。
上面已经解释了~Foo（）析构函数和！Foo（）终结器行为; 所谓的Release（）覆盖永远不会被调用，因为它不是对任何东西的覆盖，尤其是CCW提供的隐藏的IUnknown接口。 但是，这些编码错误并不意味着次要问题没有价值，并且有一些变通方法可以实现，正如我在其他答案中所述。
您可以通过IDisposable和Finalize来完成此操作。 weblogs.asp.net/cnagel/archive/2005/04/27/404809.aspx
这个答案没有直接回答这个问题，因为IDisposable和Finalize已经在C ++ / CLI~Foo（）和！Foo（）上实现了; 提问者只是不明白如何调用我在上面显示的Dispose（）方法。
解决方案4
1 2011-01-08 07:12:51
戈登，
我对这个答案很感兴趣。 你的实施没有运气吗？
查理
查理，我认为你最感兴趣的是我的答案以及下面的2.或3. 我的答案1.正如我所描述的那样工作2.但是，存在严重的问题，而不是实现3.但是为了使其保持工作，因为在检查垃圾收集的可用性时，某些事件未修补补丁，即使COM对象不符合收集条件。 方法如下，但我已经找到了一种方法来使用DotNetFramework版本4解决3的主要问题：
简洁的答案显示了如何从用C ++编写的本机非托管客户端调用IDisposable.Dispose（），它回答了直接问题。 当然这是有效的，只有原始问题撰稿人在为托管COM写作时缺乏经验才能使他感到困难。 但是，这是否可以自动完成的次要问题是我在这里真正回答的问题。
使用C ++包装器为COM可调用包装器（CCW）解决方法，该解决方案由mscoree.dll中的Microsoft COM运行时执行环境实现。 这可以发布，欢迎您使用它，主要限制如下所示：您需要在系统目录中安装DLL文件（如果在64位系统上，则需要安装它们），并且需要重新编写InProcServer32的注册表项链接到此包装器DLL（同样适用于32位和64位版本的注册表）。 DLL文件也应进行数字签名，以便某些内置Microsoft COM客户端（如Windows Imaging Component（WIC））可以接受，以便完全正常运行。
另一种解决方法纯粹来自托管代码端，它通过“修补”/“挂钩”/“调配”CCW接口的虚拟方法表来控制并添加自动调用IDisposable :: Dispose（）所需的功能。当CCW提供的伪引用计数减少为零时的派生类。 这看起来它将工作，因为我有它为非聚合实例化情况工作，但我试图支持聚合，然后我在这里提交它。 希望我能在几天内完成它。 我用C＃编写，当然它也可以用托管/ CLI C ++编写，最终将提供两个实现的链接。 这比包装器要复杂得多，但它的优势在于它非常容易使用，因为我只需要对COM服务器类进行很少的更改就可以使用它，正如我将要展示的那样，并且没有额外的工作完全安装。 这似乎是不可靠的，因为我需要做的修补因垃圾收集扫描中的某些事件而被撤消，因此我无法控制对引用计数的跟踪。
因此，优点是易于使用。 但是，有一些缺点如下：
代码通过在模拟的托管接口的情况下直接写入虚拟方法表来修补虚拟方法表，这已经能够在过去的许多年中完成但是没有保证微软未来可能不会改变它用于新版操作系统的内存模型。 我已尝试对非托管内存中的虚拟方法表的副本进行更改，但无法轻松获得某些关键功能 - Marshal.GetObjectForIunknown（）方法调用不再按预期工作，这需要一些非常混乱的静态查找表...我目前没有使用它并直接修补托管vtable。 如果Microsoft改变了写入限制，我可能会使“混乱”方法起作用。 除了使用DotNetFramework 4.0版提供的新功能外，看起来不可能。
为了保持相当简单，我目前修改了QueryInterface实现挂钩，以便忽略“额外”IMarshal ... IConnectionContainer接口，并且无法从COM访问。 如果这些是必需的，那么可以在托管代码中实现所有必需的接口 - 相当大的工作 - 或者找到一种方法来“挂钩”这些接口，这可能是因为我已经“挂钩”内部IUnknown非托管接口这是支持聚合所必需的。 但是，仍然是一项很大的编程任务。
由于非托管代码和托管代码之间的所有编组，代码可能不是很快，并且可能不适合托管COM服务器，其中对COM服务器方法的调用快速且频繁并且“细粒度”意味着每个调用都没有做得那么多。 如果所需的托管COM服务器可以通过很少的方法调用完成相当多的工作，那么它应该没问题，并且在托管代码而不是非托管C ++中实现它的性能成本应该是最小的。
这个项目更多的是一个“白骑士”黑客项目的性质，在当前的实施工作！
完成之后，我应该把它作为一篇文章提交到某个网站，例如“代码项目”，因为我认为它会对许多人有用。
无论如何，再观看这个空间使用DotNetFramework 4.0中的设备...
解决方案5
1 2011-01-08 07:48:12
在我看来，有三种方法可以解决这里提出的问题，具体如下：
当一个人直接控制本机非托管客户端时，可以直接调用IDisposable.Dispose（），如我在Answer上清楚显示的那样; 这是最简单的解决方案，但并不总能控制客户端。
根据另一个问题，当CCW引用计数被释放为零时，如何自动调用Dispose（）方法的第二个问题的答案，我已经证明可以用COM可调用包装器（CCW）的非托管代码实现包装一个非托管代码DLL，以支持此功能。 这个解决方案并不难写，但很难安装。
在之前的一篇答案中，我试图通过使用“修补”/“黑客攻击”/“挂钩”/“调配”技术来提出上述第二个问题的解决方案的第三种替代方案，以便托管代码可以完全支持该功能，因此，除了托管的DotNet COM服务器通常所需的安装之外，不需要任何额外的安装。 我已经完全放弃了这个解决方案，因为在完成它之后，包括检测和实现对客户端聚合的支持，我发现链接到垃圾收集扫描进程的某些事件导致修补的指针未修补，这意味着我的例程失去控制跟踪参考计数，从而跟踪处理过程。
在这里，我使用新的ICustomQueryInterface接口提供了对次要问题的最后一个答案，该接口仅适用于DotNetFramework 4.0版 （可能更新），这避免了必须对现有虚拟方法表进行大部分风险修补。 使用这个新接口，仍然可以创建虚拟方法表，但只需要关注控制仅在客户端聚合COM服务器时使用的内部IUnknown接口。 该方法有一个轻微但不严重的限制，我将在实施后介绍。
第二个问题实际上与为什么在COM引用计数器变为零时不会自动调用与~Foo（）析构函数关联的实际Dispose（）的原因有关，原因是COM未实现此功能可调用包装器（CCW），至少目前不是。 需要回答的第二个问题与以下问题有关：当一个人没有编写COM客户端时，一般情况下哪些客户端是在假定非托管本机代码COM服务器的情况下编写的，但COM服务器需要确定性地处理资源，如问题文本如下：
我真的很喜欢它，所以当我的原生Bar :: IFoo对象超出范围时，它会自动调用我的.NET对象的dispose代码。
在这里，提问者并不真正理解本机C ++没有用于确定基于堆栈的变量何时“超出范围”的机制，这与使用“堆栈语义”的C ++ / CLI不同，并且必须手动调用Release （）方法，如我所示。 因此，正确答案如下：
实际上，当最后一个引用被释放时，不会从COM客户端调用Dispose（或者我应该说~Foo）和Release。 它根本没有实现。 这里有一些想法可以做到这一点。
http://blogs.msdn.com/oldnewthing/archive/2007/04/24/2252261.aspx#2269675
但即使是作者也不建议这种方法。
以上是正确的，非托管Com Callable Wrapper（CCW）不是IDisposable接口感知（由~Foo（）C ++ / CLI语法自动隐含的接口），因此不调用（实际）Dispose（）方法这将触发OP（和其他所有人）的愿望。 但是，有一些解决方法可以解决这个问题，因为我在这里做出了贡献。
我考虑了“MadQ”表达的想法，按照页面底部上面链接的页面和他关于通过“挂钩”/“调配”vTable指针在托管代码中实现修复的想法，并认为这想法可能实际上有一些修改。 虽然这个想法可能不完全可取，因为人们在构建自己的vTable条目时有效地编写自修改代码，但它与CCW构建的接口代理没有什么不同，以便能够支持DotNet COM服务器。 “MadQ”概述的基本前提有很多遗漏和问题如下：
建议将IUnknown接口挂钩或“调配”，以便能够检查引用计数何时降至零，但对于更常见的非聚合情况，所有其他接口也可以更改引用计数对象实例，包括所有托管接口以及CCW自动提供的非托管接口。 最后一个可以包括IMarshal，IProvideClassInfo，ISupportErrorInfo，可能分别是ItypeInfo和IErrorInfo中最后两个的支持接口，IDispatch如果类使用AutoDispatch或AutoDual设置也将创建coclass接口，IConnectionPointContainer和IConnectionPoint如果COM事件是如果在托管类上实现IExpando接口，则实现IDispatchEx;如果托管类实现IEnumerable接口，则为IEnumVARIANT（可能存在其他未发现的接口）。
对于一旦检测到非聚合的情况，可以为所有管理的Release（）指针添加“swizzling”/挂钩，正如为IUnknown提议的那样; 但是，因为其他非托管接口是在非托管C ++中实现的，所以它们位于代码空间中，并且无法编写/修补vTable。 这可以通过在分配的Co任务内存中创建vTable的副本来解决，但是例程本身会检测到对象已经与真正的vTable分离。 造成这种情况的解决办法是使用对象实例的静态字典和指针他们属于使实际的对象可以抬起头，然后修补接口枕able指针未打补丁，调用的方法，以及指针重新修补了每个非托管接口中的每个方法 - 很多非常混乱的工作，并且在非托管代码和托管代码之间来回编组的所有流程中都不太好。 此外，支持多线程这样做存在很大的潜在问题，因此必须找到问题的其他解决方法。 因此，我试图坚持修补托管接口，并且只使用用于聚合的内部IUnknown接口的新模拟虚拟方法表; 但是我遇到了下面4中描述的严重问题。
我在http://msdn.microsoft.com/en-us/library/aa720632(VS.71).aspx]的Microsoft文档中注意到.Net类可以提供这些接口的实现，这些接口覆盖这些本机代码实现，所以所有接口都可能看起来是托管类，实现似乎取代了非托管接口。 这是一个可行的解决方案，但如果需要，在托管代码中实现所有这些接口需要大量工作。
或者，可以修改QueryInterface方法，以便生成的托管COM服务器不支持非托管接口，这在最初的问题中是最需要的。 实际上，这使得上述非托管的接口实现完全没有问题，因为QueryInterface（）的钩子化托管代码版本只能响应已实现的托管类，并拒绝对那些不需要或实现为托管版本的其他接口的任何查询的接口。 这是使用低于4.0版的DotNetFramework实现此操作的主要限制，除了垃圾收集器取消修补/恢复虚拟方法表之外，如果修补了原始IUnknown接口，则无法再使用Marshal.GetObjectForIUnknown（）和Marshal。此服务器上的GetUniqueObjectForIUnknown（），如果将DotNet托管的COM服务器作为参数传递给其他托管代码的另一个托管COM服务器对象，则必须这样做。 例如，非托管Windows映像组件（WIC）编解码器系统的某些部分可能会将托管的IBitmapDecoder对象的实例传递给托管的WPF代码，这将通过运行时可调用包装器（RCW）从此类调用方法失败，除非这些Marshal方法有效。 我没有成功地让系统认为实现是一个非托管接口，可以支持完整RCW和非托管代码。
控制这种非托管“额外”接口的另一种替代方法是将这些接口的托管实现编写为仅调用已经在CCW中实现的非托管代码，如果需要，这可能是控制这些接口的最简单方法。
最后，“MadQ”错过了一个技巧，因为CCW引用计数增加并且在链接被“挂钩”之前减少到零没有任何问题，因为它不会导致C ++类型删除并且只取消强引用托管对象实例使其不被确认和垃圾收集。 这样，一个不依赖于托管类只能用于非托管COM客户端，因为至少有一个的引用计数从不允许它为.Net客户端进行垃圾收集，因为在构造时引用计数可以保持为零尽管有一些对各种实例接口的引用。
这项技术有什么好处如下：
这种替代解决方法完全来自托管代码端，通过“修补”/“挂钩”/“调配”CCW接口的虚拟方法表来实现控制并添加自动调用IDisposable.Dispose（）所需的功能。当CCW提供的伪引用计数减少为零时的派生类。 这比包装器要复杂得多，但它的优势在于它非常容易使用，因为我会对COM服务器类进行很少的更改以便像我将要展示的那样使用它，并且没有额外的安装工作一点都不
因此，优点是易于使用。 但是，有一些缺点如下：
即使使用DotNet 4.0提供的新ICustomQueryInterface接口，也无法控制/跟踪对象实例的正常非聚合IUnknown接口，并且可以防止此接口上的查询找到任何其他不希望公开的接口对于COM，无法跟踪通过此接口完成的引用计数。 幸运的是，似乎可以控制对通常隐藏的内部IUnknown接口的引用计数的跟踪，该接口仅在客户端聚合对象时使用。
为了保持相当简单，我目前修改了QueryInterface实现挂钩，以便忽略“额外”IMarshal ... IConnectionContainer接口，并且无法从COM访问。 如果需要这些，可以在托管代码中实现所有必需的接口 - 相当大的工作 - 或者找到一种方法来“钩住”这些接口，这也可以通过少量的额外代码和研究来完成。
由于非托管代码和托管代码之间的所有编组，代码可能不是很快，并且可能不适合托管COM服务器，其中对COM服务器方法的调用快速且频繁并且“细粒度”意味着每个调用都没有做得那么多。 如果所需的托管COM服务器可以通过很少的方法调用完成相当多的工作，那么它应该没问题，并且在托管代码而不是非托管C ++中实现它的性能成本应该是最小的。
这个项目更具有“白骑士”黑客攻击项目的性质，可以解决当前的实施问题！
与Question相反，要启动，非托管COM客户端的实现只会更改为不需要调用IDisposable.Dispose（）方法（就像包装器Answer一样），如下所示：
#import "..\\Bar\\Bar.tlb" //raw_interfaces_only
...
CoInitialize(NULL);
...
//the syntax for a "Smart Pointer" is as follows:
Bar::IFooPtr pif(__uuidof(Bar::Foo)); // This object comes from the .tlb.
if (pif)
{
//This is not stack based so the calling syntax for an object instance is as follows:
pif->Doit();
//THE FOLLOWING IS NOT REQUIRED AND IS COMMENTED OUT!!!
//IDisposable *id = nullptr;
//if (SUCCEEDED(pif->QueryInterface(__uuidof(IDisposable), (LPVOID*)&id)) && id)
//{
// id->Dispose();
// id->Release();
//}
//The Release on the IUnknown is absolutely necessary, as without it the reference count stays as one!
//This would result in a memory leak, as the Bar::Foo's destructor is never called,
//and knows nothing about the IUnknown::Release() even if it were!!!
pif->Release();
}
...
CoUninitialize();
...
接下来，对托管COM服务器的唯一更改是使COM服务器类从新的AutoComDisposenC基类继承（直接或间接）。 我还添加了“保护”析构函数代码的附加功能，使其仅在第一次被调用时才有效，因为这些文件只关闭一次，等等，如下所示：
using namespace System;
using namespace System::Threading;
using namespace System::Runtime::InteropServices;
namespace Bar {
[Guid("57ED5388-blahblah")]
[InterfaceType(ComInterfaceType::InterfaceIsIUnknown)]
[ComVisible(true)]
public interface class IFoo
{
void Doit();
};
[Guid("417E5293-blahblah")]
[ClassInterface(ClassInterfaceType::None)]
[ComVisible(true)]
public ref class Foo : AutoComDisposenC, IFoo
{
//these don't need to be seen...
private:
bool disposed;
Object ^disposedlock;
void DisposeManaged() {};
void DisposeUnmanaged() {};
~Foo() // called directly or by Dispose() on this instance
{
//multi-threading safe, only effective first time it's called...
bool d;
Monitor::Enter(this->disposedlock);
//in critical section = only one thread at a time
d = this->disposed;
this->disposed = false;
Monitor::Exit(this->disposedlock);
if (!d)
{
DisposeManaged();
this->!Foo();
}
}
!Foo() {DisposeUnmanaged();} // This is called by the garbage collector and the above.
public:
Foo() : disposed(FALSE), disposedlock(gcnew Object()) {};
//THE FOLLOWING IS WRONG AS ONE CANNOT OVERRIDE THE HIDDEN IUNKNOWN RELEASE() METHOD!!!
// virtual ULONG Release() {MyDispose(); return 0;} // This is never called automatically!!!
[PreserveSig]
[ComVisible(true)]
virtual void Doit() {};
};
}
最后，将来，将是AutoComDisposenC类的实际实现：
完成后，我应该将这个备选答案作为文章提交给某些网站，例如“代码项目”，因为我认为这对许多人来说会有用。
解决方案6
0 2017-12-15 01:02:54
如果没有用C ++创建包装器（没有.NET），我不知道如何。 问题是，当对Release的调用将COM引用计数降为0时，.NET Framework不知道是否仍有未包含在COM引用计数中的托管引用。
基本限制是.NET没有只能从COM访问的对象的概念。 并且由于.NET对象的引用在垃圾收集之前无法确定，因此在发布时没有确定的处理方式，就像在纯COM中一样。
COM Interop和.NET 3.5的问题 - 调试和发布模式下的不同行为
[英]Issues with COM Interop and .NET 3.5 - different behaviors in Debug and Release mode
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.