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

[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

[Sam Gentile [MVP]]

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/de...tml/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" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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

[Dmitry]

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 [MVP]" <sa*@nomail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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/de...tml/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" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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

[Sam Gentile [MVP]]

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/de...tml/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" <dk***********@fmco.com> wrote in message
news:O6**************@TK2MSFTNGP09.phx.gbl...

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 [MVP]" <sa*@nomail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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/de...tml/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" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

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