Accessing COM Component arguments defined by "ref", after it raise COM+ error

  • Thread starter Thread starter Dmitry
  • Start date Start date
D

Dmitry

Hi,

I have defined interface for COM components which inludes an argument being
filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller application
gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
.....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
.....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses
information.
}

Thanks
Dmitry
 
First of all HRESULT types don't exist in the .NET Framework so they become
32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding to
the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes the
Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties like
ex.Message which gets stuffed with IErrorInfo.GetDescrription and Ex.Source
which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
..NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/bridge.asp
Please reply only to the newsgroup so that others can benefit.


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Sam,

strLog -- may contain from 1 to 10 K of data, depending on number of
errors, warnings coming from COM object. so packing that data in ErrorInfo
properties might be waste of resource.
Code is written for interaction within COM environment, but now I am looking
in compatibility with .Net callers.

Sam Gentile said:
First of all HRESULT types don't exist in the .NET Framework so they become
32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding to
the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes the
Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties like
ex.Message which gets stuffed with IErrorInfo.GetDescrription and Ex.Source
which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
.NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/bridge.asp
Please reply only to the newsgroup so that others can benefit.


This posting is provided "AS IS" with no warranties, and confers no rights.
Dmitry said:
Hi,

I have defined interface for COM components which inludes an argument being
filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller application
gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses
information.
}

Thanks
Dmitry
Click to expand...
Click to expand...
 
I am describing what the COM Interop marshaler does to your COM types in
..NET. You *don't* get a choice (unless you write a custom RCW or marshaler)

--
Sam Gentile [C#/.NET MVP]
..NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/bridge.asp
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.


Dmitry said:
Sam,

strLog -- may contain from 1 to 10 K of data, depending on number of
errors, warnings coming from COM object. so packing that data in ErrorInfo
properties might be waste of resource.
Code is written for interaction within COM environment, but now I am looking
in compatibility with .Net callers.

Sam Gentile said:
First of all HRESULT types don't exist in the .NET Framework so they become
32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding to
the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes the
Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties like
ex.Message which gets stuffed with IErrorInfo.GetDescrription and Ex.Source
which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
.NET Blog http://samgentile.com/blog/
MSDN Column:
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/bridge.asp
Please reply only to the newsgroup so that others can benefit.


This posting is provided "AS IS" with no warranties, and confers no rights.
Dmitry said:
Hi,

I have defined interface for COM components which inludes an argument being
filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller application
gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses
information.
}

Thanks
Dmitry
Click to expand...
Click to expand...
Click to expand...
 
Back
Top