Mismatched parameters from method after moving to OE11.7.2

Posted by RJPowell on 29-Nov-2019 11:44

Morning,

We have recently produced our first release using OpenEdge 11.7 and discovered an error when interfacing with a certain piece of equipment, which has necessitated some customer systems returning to using OpenEdge 11.6.  The error is coming from within a library which is certified by Weights & Measures, so by necessity has been totally unchanged for a number of years.  In fact, it has remained so unchanged that we still distribute an OpenEdge 11.3 version of the pl file for it (the first thing we tried was building it under 11.7 as the obvious answer was that there was just an incompatibility between versions).

The code causing the error is along the lines of:

using System.IO.Ports.*.

class bcp.weighscale.WeighScale:

method public integer Initialize(someParameters):

define variable myPort as SerialPort no-undo.

define variable errorCode as integer no-undo.

openPort(output myPort, output errorCode).

return errorCode.

end method.

method private void openPort(output myPort as SerialPort, output errorCode as integer):

myPort = new SerialPort(someParameters).

if valid-object(myPort) then

myPort:Open().

/* Some checks to set errorCode go here */

end method.

end class.

This produces no syntax errors, compiles just fine, but when you try to run it you get:

Source class 'System.IO.Ports.SerialPort, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not compatible with target class 'Progress.Lang.Error' for parameter 'myPort'. (13016)
Routine Initialize bcp.weighscale.WeighScale sent called routine openPort bcp.weighscale.WeighScale mismatched parameters. (2570)

As stated above, this code has been unchanged for years and has worked through OpenEdge 11.3 -> 11.6.  It has only started doing this after moving the system to OpenEdge 11.7.2.  Any assistance or ideas would be greatly appreciated, because I'm a little stumped here.

Cheers,

Robin

Posted by RJPowell on 05-Dec-2019 16:11

So, irritatingly, after pulling my hair out all week, all it needed was a rebuild under OE11.7.  Turns out that a mistake in QA meant they were constantly retesting the same old version rather than anything new we were producing.  So we've had the answer for a while.  Decided this morning to take a step back and start evaluating everything right from the most basic principles, and there the problem was.  Probably should have done that earlier.

Posted by RJPowell on 05-Dec-2019 16:17

So, irritatingly, we actually fixed this early last week by rebuilding the library under OE11.7.  A mistake with the testing was producing erroneous results.

All Replies

Posted by Roger Blanchard on 29-Nov-2019 13:32

Is it possible you are compiling against a different version of 'System.IO.Ports.SerialPort" than what you production pc has? We have seen this when we have different versions of assemblies on our dev pc than our production pc.

Posted by RJPowell on 29-Nov-2019 15:40

Thanks Roger.  I hadn't considered it, but I guess it is possible that removing the OE11.6 web client from the system and adding the 11.7 one might have done something with the .net assemblies.  We'll have a look into that.

Posted by RJPowell on 05-Dec-2019 16:11

So, irritatingly, after pulling my hair out all week, all it needed was a rebuild under OE11.7.  Turns out that a mistake in QA meant they were constantly retesting the same old version rather than anything new we were producing.  So we've had the answer for a while.  Decided this morning to take a step back and start evaluating everything right from the most basic principles, and there the problem was.  Probably should have done that earlier.

Posted by RJPowell on 05-Dec-2019 16:17

So, irritatingly, we actually fixed this early last week by rebuilding the library under OE11.7.  A mistake with the testing was producing erroneous results.

This thread is closed