|
|
You're in the
dotnet interop
group:Returning COM Interface from Unmanaged DLL Function via PInvoke
dotnet interop:
parameter from a function in an unmanaged DLL called via the Platform Invoke? An example of this is the function HRESULT CoGetMalloc(DWORD dwMemContext, LPMALLOC * ppMalloc); or its declaration in C# [System.Runtime.InteropServices.DllImport("ole32.dll")] int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); I couldn't locate any information about this in the documentation of the ..NET Framework. In particular, will the marshaling layer make one extra AddRef call on the COM interface in addition to the original AddRef call in the implementation of the function. The latter call, as you know, is required by the reference counting rule of COM. Thanks.
Correction, the declaration in C# should read
[System.Runtime.InteropServices.DllImport("ole32.dll")] public static extern int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); Thanks. [quoted text, click to view] "jorfei" wrote:
> What is the marshaling behavior for a COM interface returned with an output > parameter from a function in an unmanaged DLL called via the Platform Invoke? > An example of this is the function > > HRESULT CoGetMalloc(DWORD dwMemContext, LPMALLOC * ppMalloc); > > or its declaration in C# > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > I couldn't locate any information about this in the documentation of the > .NET Framework. > > In particular, will the marshaling layer make one extra AddRef call on the > COM interface in addition to the original AddRef call in the implementation > of the function. The latter call, as you know, is required by the reference > counting rule of COM. > > Thanks.
I don't know the answer to your question, so I could be way off here.
But I wonder if it matters considering that your .NET code will utilize the RCW for the COM object, and the RCW will make sure the COM object won't go out-of-scope (get released) as long as the wrapper itself is reachable. (In fact, people generally have the opposite problem...that their COM objects live *longer* than they intended). Tom [quoted text, click to view] jorfei wrote:
> Correction, the declaration in C# should read > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > public static extern int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > Thanks. > > "jorfei" wrote: > > > What is the marshaling behavior for a COM interface returned with an output > > parameter from a function in an unmanaged DLL called via the Platform Invoke? > > An example of this is the function > > > > HRESULT CoGetMalloc(DWORD dwMemContext, LPMALLOC * ppMalloc); > > > > or its declaration in C# > > > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > > int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > > > I couldn't locate any information about this in the documentation of the > > .NET Framework. > > > > In particular, will the marshaling layer make one extra AddRef call on the > > COM interface in addition to the original AddRef call in the implementation > > of the function. The latter call, as you know, is required by the reference > > counting rule of COM. > > > > Thanks. > >
It is exactly with this opposite effect that I'm concerned. If the marshaling
layer has called AddRef on the COM interface returned, it means when the RCW is garbage-collected, the corresponding COM object will not be destroyed. The reference counting rule of COM requires that the callee (i.e. the implementation) returning the COM interface to increment the reference count so that the caller needs only to call Release on the COM interface when the COM interface is no longer required. Thanks. [quoted text, click to view] "TDC" wrote:
> I don't know the answer to your question, so I could be way off here. > But I wonder if it matters considering that your .NET code will utilize > the RCW for the COM object, and the RCW will make sure the COM object > won't go out-of-scope (get released) as long as the wrapper itself is > reachable. (In fact, people generally have the opposite problem...that > their COM objects live *longer* than they intended). > > Tom > > jorfei wrote: > > Correction, the declaration in C# should read > > > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > > public static extern int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > > > Thanks. > > > > "jorfei" wrote: > > > > > What is the marshaling behavior for a COM interface returned with an output > > > parameter from a function in an unmanaged DLL called via the Platform Invoke? > > > An example of this is the function > > > > > > HRESULT CoGetMalloc(DWORD dwMemContext, LPMALLOC * ppMalloc); > > > > > > or its declaration in C# > > > > > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > > > int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > > > > > I couldn't locate any information about this in the documentation of the > > > .NET Framework. > > > > > > In particular, will the marshaling layer make one extra AddRef call on the > > > COM interface in addition to the original AddRef call in the implementation > > > of the function. The latter call, as you know, is required by the reference > > > counting rule of COM. > > > > > > Thanks. > > > >
Hi,
Currently I am researching the issue, and I will update you ASAP. BTW: In .NET, we have a method Marshal.AllocCoTaskMem which will do the same job, did you have any concern to use it directly? Best regards, Peter Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Peter,
I'm aware of that. I'm just quoting this function as an example. Thanks. Best regards, jorfei [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> Hi, > > Currently I am researching the issue, and I will update you ASAP. > BTW: In .NET, we have a method Marshal.AllocCoTaskMem which will do the > same job, did you have any concern to use it directly? > > Best regards, > > Peter Huang > > Microsoft Online Community Support > ================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Do you have any reason to believe that .NET interop will behave
incorrectly in this manner? It seems like it should be a simple thing to test the behavior one way or the other. If I get a chance I'll do so and post my results. Good luck, Tom [quoted text, click to view] jorfei wrote:
> It is exactly with this opposite effect that I'm concerned. If the marshaling > layer has called AddRef on the COM interface returned, it means when the RCW > is garbage-collected, the corresponding COM object will not be destroyed. The > reference counting rule of COM requires that the callee (i.e. the > implementation) returning the COM interface to increment the reference count > so that the caller needs only to call Release on the COM interface when the > COM interface is no longer required. > > Thanks. > > "TDC" wrote: > > > I don't know the answer to your question, so I could be way off here. > > But I wonder if it matters considering that your .NET code will utilize > > the RCW for the COM object, and the RCW will make sure the COM object > > won't go out-of-scope (get released) as long as the wrapper itself is > > reachable. (In fact, people generally have the opposite problem...that > > their COM objects live *longer* than they intended). > > > > Tom > > > > jorfei wrote: > > > Correction, the declaration in C# should read > > > > > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > > > public static extern int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > > > > > Thanks. > > > > > > "jorfei" wrote: > > > > > > > What is the marshaling behavior for a COM interface returned with an output > > > > parameter from a function in an unmanaged DLL called via the Platform Invoke? > > > > An example of this is the function > > > > > > > > HRESULT CoGetMalloc(DWORD dwMemContext, LPMALLOC * ppMalloc); > > > > > > > > or its declaration in C# > > > > > > > > [System.Runtime.InteropServices.DllImport("ole32.dll")] > > > > int CoGetMalloc(uint dwMemContext, out IMalloc ppMalloc); > > > > > > > > I couldn't locate any information about this in the documentation of the > > > > .NET Framework. > > > > > > > > In particular, will the marshaling layer make one extra AddRef call on the > > > > COM interface in addition to the original AddRef call in the implementation > > > > of the function. The latter call, as you know, is required by the reference > > > > counting rule of COM. > > > > > > > > Thanks. > > > > > > > >
Hi Jorfei,
So far I am still researching the issue and I will update you with new information ASAP. Thanks for your understanding, please feel free to let me know. Best regards, Peter Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Jorfei,
Sorry for delay response, because the concrete implement of .NET 2.0 CLR is not public, and based on my research I did not find information about the detailed implement detailed. But from the sample from the code project we should call the Marshal.ReleaseComObject to release the IntPtr from P/Invoke. http://www.codeproject.com/csharp/csdoesshell1.asp http://dotnetdebug.blogspot.com/2005/07/marshalreleasecomobject-and-cpu.html Also I do recommend you call Marshal.ReleaseComObject to explicitly release a com object when you will not use the COM any longer. If you have any concern, please feel free to let me know. Best regards, Peter Huang Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Peter,
I check through the code in http://www.codeproject.com/csharp/csdoesshell1.asp and doubt that it is entirely correct. In the code SHGetMalloc is declared as below: [DllImport("shell32.dll")] public static extern Int32 SHGetMalloc(out IntPtr hObject); Without further qualification, how could the runtime know that hObject is an interface pointer and know how to release it properly after use? Indeed this is where the author of the article has missed. Marshal.ReleaseComObject only releases the interface pointer up to the point where Marshal.GetTypedObjectForIUnknown is called and a call to Marshal.Release is required to fully release the interface pointer: Marshal.Release(hObject); I have written simple COM servers to research further on returning COM interface from an unmanaged DLL via PInvoke. For the benefit of other readers, the outcome of my research follows. Using SHGetMalloc as an example, the following three methods are equally correct way of getting an interface pointer via PInvoke and properly releasing it after use (error handling has been omitted). Method 1: [DllImport("shell32.dll")] public static extern int SHGetMalloc(out IMalloc pMalloc); IMalloc pMalloc; SHGetMalloc(out pMalloc); // Do something useful with pMalloc here Marshal.ReleaseComObject(pMalloc); // Calling Marshal.ReleaseComObject is optional // If it is not called, the runtime will release pMalloc when it is garbage collected Method 2: [DllImport("shell32.dll")] public static extern int SHGetMalloc(out IntPtr malloc); IntPtr malloc; SHGetMalloc(out malloc); IMalloc pMalloc = (IMalloc)Marshal.GetObjectForIUnknown(malloc); // Do something useful with pMalloc here Marshal.ReleaseComObject(pMalloc); // Calling Marshal.ReleaseComObject is optional // If it is not called, the runtime will release pMalloc when it is garbage collected Marshal.Release(malloc); Method 3: [DllImport("shell32.dll")] public static extern int SHGetMalloc([MarshalAs(UnmanagedType.Interface)] out object malloc); object malloc; SHGetMalloc(out malloc); IMalloc pMalloc = (IMalloc)malloc; // Do something useful with pMalloc here Marshal.ReleaseComObject(pMalloc); // Equivalently Marshal.ReleaseComObject(malloc); // Calling Marshal.ReleaseComObject is optional // If it is not called, the runtime will release pMalloc / malloc // when it is garbage collected Thanks. Best regards, jorfei [quoted text, click to view] ""Peter Huang" [MSFT]" wrote:
> Hi Jorfei, > > Sorry for delay response, because the concrete implement of .NET 2.0 CLR is > not public, and based on my research I did not find information about the > detailed implement detailed. > > But from the sample from the code project we should call the > Marshal.ReleaseComObject to release the IntPtr from P/Invoke. > http://www.codeproject.com/csharp/csdoesshell1.asp > > http://dotnetdebug.blogspot.com/2005/07/marshalreleasecomobject-and-cpu.html > > Also I do recommend you call Marshal.ReleaseComObject to explicitly release > a com object when you will not use the COM any longer. > > If you have any concern, please feel free to let me know. > > Best regards, > > Peter Huang > > Microsoft Online Community Support > ================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Jorfei,
Thanks for your knowledge sharing. If you still have any concern, please feel free to post in the newsgroup. Best regards, Perter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |