Problem:

Unmanaged Cobol class has a method returning "pic x" data. Unmanaged Cobol class is compiled to dll and registered (regsvr32) regarding to rules "to use rcw to call unmanaged Cobol". A VB.NET application invokes the Cobol class (added to vb.net application references as COM) and succesfully receives the returning "pic x" data.

In Unmanaged Cobol, method's returning data type is changed to "pic x(4) comp-5" to return integer value to vb.net app. Cobol app is rebuilt, unregistered and registered again. Cobol COM is removed from  vb.net app references and added again to expose returning value data type change to vb.net. But  returning value data type change doesnot expose to vb.net app, vb.net app still recognises the data type as string not integer.

What may cause such behavior?

Resolution:

This behaviour is caused by the way that COM describes its interfaces.

When you change the return type in the COBOL it does not change the way the return value is described to the outside world. You also need to change Interface definition language (IDL) that describes the interface. In an unmanaged COBOL project this will be in a file xxxxx_if.idl where xxxx is your interface name.

In a test here I changed it as follows:-

        [id(DISPID_MFTEST1_METHOD1)]

HRESULT method1 (

                [in, out] long * lnk1,

                [in, out] long * lnk2,

       // *** MFTECH Needs to be changed to int  [out, retval] BSTR* ret);

                [out, retval] long * ret);   // MFTECH - CHANGED to long

    // OCWIZARD - end methods

    };

This now specifies that the return value is a "long" which is a "System.Int32" in .Net.

If you make the change rebuild and then remove and add the reference in VB.Net then you should see the interface as expected.