Bug 7597

DotNetAssembly and DotNetObject and .NET DLL Importer - problem with the transfer of parameters of the array type 12 January, 2022

Jiri Ptacek
05 December, 2021
Product: PowerBuilder Category: DataWindow
Version: 2019 R3 Build: 2703
Classification: Appeon bug Publishing: Public
Priority: P3
Status: Scheduling Reason:
Mark Lee @Appeon 12 January, 2022
#9
Hi Jiri,

Thanks for your feedback.
For issue #1, we will update you here if there is any update from our development.

Regards,
Mark Lee
Jiri Ptacek 12 January, 2022
#8
Hi Mark Lee,
thank you for your answers.
For the issue when you "call crypt first and then of_sf_ToString (FrameWork), then the error" we are waiting for your answer.

RE: the second issue: thanks a lot, it is clear.

Best regards
Jiri
Mark Lee @Appeon 28 December, 2021
#7
Hi Jiri,

For the issue when you "call crypt first and then of_sf_ToString (FrameWork), then the error", we can reproduce it on our side and will do further research to figure it out. We will keep you updated!

Miguel is right. According to our in-depth analysis, we believe that setting the blob variable to readonly in your current case is incorrect, because this will lead to the mismatched argument passing type, which will cause a crash issue. So the previous reply was not accurate. In this case, you have to use "value" or "Reference" instead of "Readonly" and you need to ensure that the definition of the blob variable ablo_ab_data in the function is consistent with the passing type in the assembly's sf_tostring method.

Regards,
Mark Lee
Miguel Leeuwe 28 December, 2021
#6
Hi, sorry for jumping in.
In this case, ideally, the "compiler" should not allow you to use "readonly" for array parameters. People who have been working for many years with powerbuilder will never consult the documentation / help on this.
regards
Kai Zhao @Appeon 22 December, 2021
#5
Hi Jiri,

Thanks for your valuable suggestion. We will suggest the document team make modifications accordingly. And we need more time to analyze your issue, we will get back to you if we need additional information or any progress we would make.

Regards,
Kai
Jiri Ptacek 22 December, 2021
#4
Step_test2.zip (159KB)

Hi Mark Lee,
it is clear from you that you do not recommend using ReadOnly parameter passing for the blob.
the blob variable is special, it is not recommended that you use "ReadOnly"
However, this information should be described and emphasized in the help and documentation.
Like: The underlying code for passing arrays is generally by "reference".
This is not described anywhere.
We already know this, but it took a lot of our time and yours.
 
And now to the second problem (error notification after calling crypt.dll first).
You wrote that the library Test_Blob.dll is not (as we wrote) .NET Framework but .NET core.
I don't know how he found out. When we created the library, we had it set to be .NET Framework.
There is also an image in the zip, what is the setting in FrameWork.
If there is anything else to set up to actually create the .NET Framework library, please advise.
 
In the example, we added a library of the same but made (according to us) as .NET core Test_Core.dll
 
The customer has also prepared a simplified library s_crypt.dll and added source code in Pascal.
Compiled in FreePascal 2.4.2 windows x68
https://www.freepascal.org/download.html
 
with the following settings:
Compile Target Win32 for i386
Compiler switches are checked as follows – everything else is unchecked
Options Mode Debug
Options Compiler syntax switches Allow LABEL and GOTO
Options Compiler compiler mode delphi compatible
Options Compiler generated code optimizations generate smaller code
Options Compiler Processor optimization target processor Pentium2/PentiumM/AMD
Options Compiler Processor Code generation target processor Pentium2/PentiumM/AMD
Options Compiler Browser no browser
Options Compiler Assembler Assembler reader AT&T style assembler
Options Compiler Assembler Assembler Output Use default output
Options Debugger Strip All Debug symbols form executable
Options Debug information generation
 
And now to the behavior of using libraries:
a.	If I call crypt first and then of_sf_ToString (FrameWork), then the error
b.	If I call first of_sf_ToString (FrameWork) and then crypt, then OK
c.	If I call first crypt and then of_sf_ToString (Core), so OK
d.	If I call first of_sf_ToString (Core) and then crypt, so OK
If I change in nvo_test_blob. of_createOnDemand( ) call from LoadWithDotNetFramework to LoadWithDotNetCore
e.	Then there is also point a) OK
 
It's laboratory work, but I'm a little afraid that in the area of calling *.dll, everything is not completely kosher and that if we find a "way", it will work for us, but "random" problems may begin to appear. It sometimes happens when the application crashes for a completely unknown reason without any error reporting.
Although very rarely, but it happens....
 
Here is an opportunity to try to verify if there is any hidden bug somewhere that appears only under specific conditions.
 
Conclusion:
•	Please describe in Help how to pass parameters of the blob and array type. Respectively, what is the recommendation of PB developers.
•	Now we no longer need to find a "path", but rather to check whether in the given (described) situation of calling *.dll there is a bug that remains hidden in other circumstances.
 
Thank you in advance for your good cooperation.
Best regards
Jiri
Mark Lee @Appeon 08 December, 2021
#3
new test case

Hi Jiri,

Thanks for providing the test case.
For the case you provided, I can only use the PB 2021 version to open and run it. But the version you chose when you reported the bug was PB 2019 R3 2703.
The .NET library Test_Blob.dll you provided is shown as .NET core library DLL on my computer instead of the .NET Framework library DLL you mentioned.
So I rebuilt this test case and found that it works fine in the development environment and runtime environment (refer to the attachment).
You can download the attachment to verify whether it also works for you.
 
BTW, the blob variable is special, it is not recommended that you use "ReadOnly", but instead you can use  "Value" or "Reference". The underlying code for passing arrays is generally by "reference".
In addition, if I misunderstood, please provide us with the complete source code for Test_Blob.dll for us to verify and analyze.

Regards,
Mark Lee
Jiri Ptacek 07 December, 2021
#2
Step_test.zip (91KB)

Hi Chris,

Thanks.
To your question 1: Both problems are demonstrated on blob – byte[] , 
problem 2) is also identified on char[] – char[]
There are NO problems with simple string type.

The customer prepared simple demo – see attached.
There 3 buttons in the example.
Program includes:
-	Testing window
-	Object created from FrameWork library *.dll using .NET DLL Importer (there is also a source code attached – transfer from blob to string)
-	*.dll library which can hash the test example and returns it as a hexa-string.

The problems/errors: 
1.	Fall of the program
Press the ReadOnly button or Reference and then ReadOnly.
PowerBuilder will fall without any error message.
Description:
The button Reference calls .net as the Importer created.
The button ReadOnly calls .net via clone of the function, where the input parameter BLOB is transferred by reference with ReadOnly.
Called .net function does not change the input BLOB, it just reads it. As per help the transfer of the ReadOnly references is without an option to change the link.
So the value should not change, there should not be any problem.
But the application will fall.

2.	Error announcement : Error calling external object function
After run of the development env. and the program, press the button “Crypt” first.
After that you can press “Reference” or “ReadOnly” – you will always get an error.
When you will exit the program (not the development env.) and run it again, you will always get an error.

When you will press the button “Reference” first just after the run of the development env., then you can press “Crypt” or “Reference” without any error.   

The problem is that it is unpredictable behavior, so we can’t expect when it will run or fall.

Thank you in advance for your help.
Best regards
Jiri
Mark Lee @Appeon 05 December, 2021
#1
Hi Jiri,

Thanks for reporting this problem.
We couldn't locate the cause of the issue based on your description. Please help provide the information below:
1. Which data array type caused this error?
2. Please provide a sample reproducible test case (including the PBT/PBL and .Net Class library) to us for more study. Thanks in advance!

Regards,
Mark Lee
Jiri Ptacek 05 December, 2021
Hello,

Our customer with PowerBuilder wrote us about his problem with calling .dll libraries using DotNetAssembly and DotNetObject and .NET DLL Importer. The problem is with the transfer of parameters of the array type.

As per documentation https://docs.appeon.com/pb2019r2/application_techniques/ch20s01.html#csharp_data_types
it sould work and the importer should prepare and map it. But it does not work.
   
Called tested function is very simplified in .net.
Transfer of other non-array parameters is working fine.

There is an error message: Error calling external object function xxxxxxx (…there is an exception in external part) at line 23 in function of_xxxxxxx of object nvo_test_pb.
Part of the error is probably from PB and part of it is from .net. 
The error was captured using try – catch.
 
The same behavior is in PowerBuilder 2021.

Thank you for your help.
Best regards
Jiri
OS:
Windows 10
Platform:
64-bit
Database Type:
Oracle
Database Version: