1. Les Kaplan
  2. PowerBuilder
  3. Wednesday, 2 March 2022 16:23 PM UTC

Hello,

So we migrated to PowerBuilder 2019 and the previous version called a .Net Dll 4.52 framework. I followed all the instructions to import to a NVO that calls the dll and set the assembly to a direct path that everyone has as well as the one that lives with the folder in the app, so I tried it both ways. I can run the application remotely, but none of my users can call the dll from the PowerBuilder application. The connection to the dll returns a -3 for them. I have added all the required dlls for .net that was in the instructions and made sure we had all the frameworks were installed, including the C runtime. 

Can you tell me am I missing something here? Any information would be appreciated.

 

 

Here are the instructions I followed without any luck with my users:

When the PowerBuilder application is deployed, the system DLLs such as PBDotNet190.dll, PBDotNetFrameworkInvoker190.dll, and PBDotNetCoreInvoker190.dll will be deployed automatically. However, you will need to make sure the .NET DLLs as well as any dependent DLLs are deployed in the same folder.

And also make sure the target machine have Universal CRT (C Runtime) and the required .NET Framework or .NET Core installed in order to run the .NET DLLs.

 

Thanks,

Les Kaplan

Mark Lee @Appeon Accepted Answer Pending Moderation
  1. Thursday, 3 March 2022 05:03 AM UTC
  2. PowerBuilder
  3. # 1

Hi Les,

Since you said it worked when you run the application remotely, I think it should be related to environmental configurations, such as the configuration of PB Runtime.

Because you mentioned importing NVO, I suggest that you check the path of the variable is_ assemblypath in the NVO and see if it refers to the path of the Assembly DLL on your client machine. As shown below: The is_assemblyPath variable refers to DemoAPI.dll using a relative path, so the DLL should be with the same folder as the exe file.

BTW, what is the build No. of your PB 2019?

If it is PB 2019 R3 Build 2670 or later version, you need to check that the runtime path in the compile-time generated XML file (same name as the exe) points to the valid path.

 

Regards,

Comment
There are no comments made yet.
Les Kaplan Accepted Answer Pending Moderation
  1. Wednesday, 2 March 2022 20:18 PM UTC
  2. PowerBuilder
  3. # 2

It was set to the .Net Framework on the import. You have to use either .net core or a asp.net. Thanks for the response, but we are handling that already.

Comment
  1. Miguel Leeuwe
  2. Thursday, 3 March 2022 03:26 AM UTC
If you are using a hardcoded fixed path, then what you say about "you will need to make sure the .NET DLLs as well as any dependent DLLs are deployed in the same folder" might no longer be the case. The library would have to be in that hardcoded path.

regards
  1. Helpful
  1. John Fauss
  2. Thursday, 3 March 2022 04:54 AM UTC
Also, if you are using PB 2019 R3 (and PB 2021), the version number suffix ("190") on the DLL names have been removed. I mention this because you did not let us know which release of PB 2019 you are using.
  1. Helpful
  1. Miguel Leeuwe
  2. Thursday, 3 March 2022 06:24 AM UTC
And just in case: Are you sure your end-users have to correct .net framework installed?
  1. Helpful
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 2 March 2022 19:03 PM UTC
  2. PowerBuilder
  3. # 3

When you use the DLL importer tool, you have to specify if it's a .Net framework or .Net Core DLL if I remember well. Make sure you choose the .Net Framework in your case.

regards

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.