Error 13016 when passing .NET-based classes as parameters in

Posted by bheavican on 14-Mar-2012 13:47

I received this in a PANS email today.  When I read it, it just seems wrong for an error to be thrown or at least the error text makes it look like it should be working.  System.Object is not compatible with System.Object and the rest of the information is the same.  Can someone please explain what I'm missing here?
EnvironmentOpenEdge 11.0
Windows
Question/Problem Description
Error 13016 is raised when running r-code that passes a class based on System.Object (sometimes called a "hybrid" class) as a parameter in OpenEdge 11.0. The format of the message is similar to the following.

Source class 'System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not compatible with target class 'System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' for parameter 'poSender'. (13016)
Clarifying Information
The same code does not raise an error in OpenEdge 10.2B05.
The error is not raised when running source code (p-code).
Error MessageSource class '<class>' is not compatible with target class '<class>' for parameter '<parameter-name>'. (13016)
Defect/Enhancement NumberDefect OE00217049
Cause
The AVM cannot find object type information for .NET-based classes in r-code. In OpenEdge 11.0, object type information is used to check parameter compatibility at run time. Because the full object type information is not available for .NET-based classes, the compatibility check fails and error 13016 is raised.

In OpenEdge 10.2x, object type information is only checked at compile time, when it is available. Since no parameter compatibility checking is done at run time, error 13016 is not raised.

If p-code is compiled and run in the same session ("compiled on the fly"), all necessary object type information is available for the run-time compatibility check, and error 13016 is not raised.
Resolution
None at this time.
Workaround
Notes
Attachment
DisclaimerThe origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.

All Replies

Posted by Laura Stern on 14-Mar-2012 15:00

You are not missing anything.  Of course a System.Object should be compatible with a System.Object.  That's why this is a bug.  It is fixed in 11.1.

Posted by bheavican on 14-Mar-2012 15:24

Thanks,  I got worried when I saw that it did not have a resolution at this time.

Posted by Laura Stern on 14-Mar-2012 16:06

Oh... and it's also fixed in an 11.0 patch.

This thread is closed