Bug 6464

RuntimePath - aplication.xml - PBVM.dll not found 28 April, 2021

Walter Ruaro
22 April, 2021
Product: PowerBuilder Category: Runtime
Version: 2019 R3 Build: 2703
Classification: Issue Publishing: Public
Priority: P3
Status: Closed Reason: RESOLVED
Chris Pollach @Appeon 28 April, 2021
Hi Walter;

  Sounds like a good longer term plan!

  I will now close this ticket.

Regards ... Chris
Walter Ruaro 28 April, 2021
Hi Ken and Chris

Thank you for your answers.

That's why from the beginning it was strange to me that it works with DLLs. When basically these files must be in the windows path or in the same folder of the application. Just for being DLL and by definition of the same.

Again, thank you both

The ticket can be closed.

We will analyze changing to the option to generate P-Code, to then also take advantage of the new PowerClient.

Ken Guo @Appeon 28 April, 2021
Hi Walter & Chris,

BTW, We don’t have a plan to enable Machine Code to support Runtime as well at the moment. Therefore if you need to use Runtime, please compile your application via P-Code.

Ken Guo @Appeon 28 April, 2021
Hi Walter,

Did you compile your application via Machine Code? If that is the case, it will only work after you do the following operation:
“Starting from version 2019 R3, a machine-code executable must add the location of PowerBuilder Runtime to the path environment variable or copy the runtime files to the same directory as the executable, before it can be run.”

You can find more detailed information in PB Help documentation:

Chris Pollach @Appeon 27 April, 2021
Hi Walter;

  Thank you so much for the Test Case!

  I have reworked your test case and attached it to this ticket. I have also found the runtime issue ... Machine Code vs P-Code!

  PB2019R3's "decoupled" runtime is supported only when the PB App(s) are compiled into either 32bit or 64bit P-Code. Machine code is *not* supported currently. In my reworked test case of yours, I have now created three projects that will compile an EXE of each type. You should see that the P-Code compiles run OK via their XML files on the deployment PC (locating the PB runtime). The M-Code EXE will fail (as expected).

  If you wish to use M_Code compiles, please workaround this unsupported decoupled runtime via:

1) Adding the PB runtime folder to your O/S's System Path  // OR

2) Create a BAT file that sets the runtime path first and then launches the PB App's EXE

  I will also now transfer this ticket over to the main Support / Engineering team to see if they have a plan to support M-Code & decoupled the decoupled runtime in the near future.

  In the meantime, please compile your PB App(s) via P-Code to ensure that the decoupled runtime feature works OK on your deployment machines.

Regards ... Chris
Chris Pollach @Appeon 27 April, 2021
Test Case (By Chris)
Walter Ruaro 27 April, 2021
test.zip (176KB)

Walter Ruaro 27 April, 2021
Screenshot_17.jpg (227KB)

108 / 5000
Resultados de traducción
Attached test.

It fails both in the PC with windows just installed, as in mine, which is the one with PB R3 

Walter Ruaro 27 April, 2021
Screenshot_16.jpg (46KB)

Walter Ruaro 27 April, 2021
Screenshot_15.jpg (37KB)

Walter Ruaro 27 April, 2021
Screenshot_14.jpg (66KB)

Walter Ruaro 27 April, 2021
Screenshot_13.jpg (106KB)

Walter Ruaro 27 April, 2021
Screenshot_12.jpg (85KB)

Hello good Morning.

I attach images of the project and I am setting up the environment with TestAPP

Chris Pollach @Appeon 26 April, 2021
Hi Walter;

  Interesting ... all my Test Apps work OK if the <AppName>.xml file points to where the R3 RT is actually installed on my PB2019R3 test PC. I even copied one of my XML files over to your older & renamed it to your App's EXE name ... failed. It seems that only your App has the issue.

  Can you take some screen captures of your PC Project compile settings and attach them to this ticket. Many thanks in advance!

  Also, can you create a simple Test PB App EXE and see if that EXE + it's XML file work OK on your deployment PC?

Regards ... Chris
Walter Ruaro 26 April, 2021

if that error of the fonts is correct. The application controls the installation of certain fonts. But the good thing is that it gets to run.

Maybe you have the powerbuilder runtime in the windows path?

How can it be that for us, with a totally clean windows and pointing the RuntimePath variable to c: \ QTECH \ axonico \ Runtime it does not work for us.

I reiterate, we only install windows, and copy the axonico folder within QTECH.
Chris Pollach @Appeon 26 April, 2021
Hi Walter;

   Thank you for the test case. Unfortunately, the App errors out with a Font error message (see attached). However, the App starts OK with or without the runtime in the App's sub-folder. By deleting your RT folder, I can use my already installed runtime by changing your "axonico.XML" file to match where my same RT is installed on my W10 machine. The app still starts but I am still getting the same Font error.

Regards ... Chris
Chris Pollach @Appeon 26 April, 2021
Error Screen from Test Case (by Chris)
Walter Ruaro 26 April, 2021
Screenshot_10.jpg (47KB)

Hello Chris.

I tell you that we did the tests on a clean PC, with windows just installed and it doesn't work.

I leave you in the following link with the complete application so that you can test it in your environment:

www.axonico.ar \ downloads \ axonico.zip

You must decompress it in "c: \ QTECH", leaving the application in "c: \ QTECH \ axonico".

When you run axonico.exe you will see that the error that I attach in the image occurs.

On the other hand, if I copy the content of the folder "c: \ QTECH \ axonico \ Runtime" in the folder "c: \ QTECH \ axonico" the system works correctly.

Can I explain?
Walter Ruaro 22 April, 2021
Hello Chris.

If I know it was always like that, only that it should be in the path of the operating system.

Currently I can not make it work as you tell me.

Tomorrow I am going to do an installation from scratch on another PC, I document it and I will send it to you.

Thanks for the answers today.
Chris Pollach @Appeon 22 April, 2021
Hi Walter;

 Yes, the PB RT DLLs can always be in another folder. It's been that way since PB 1.0. The only difference now is the use of the XML file to locate the RT DLLs vs having to add the PB RT DLL folder to the O/S System Path (old way).

  The key with the XML file is that the <RuntimePath=xxxxxxxx</RuntimePath> setting in the XML file matches 100% where the PB runtime DLL's are actually installed.

Regards ... Chris
Walter Ruaro 22 April, 2021
Currently I am testing on the same PC that I have PowerBuilder installed, therefore all the runtime DLLs are in the folder:

"c: \ Program Files (x86) \ Appeon \ Common \ PowerBuilder \ Runtime \"

and the file <application> .xml points to that same location.

In short, can the application be in one folder and the runtime in another?

In our case:
c: \ QTECH \ axonico \ axonico.exe

XML file:
c: \ QTECH \ axonico \ axonico.xml

Dll Runtime:
"c: \ Program Files (x86) \ Appeon \ Common \ PowerBuilder \ Runtime \"

or any other than c: \ QTECH \ axonico \
Chris Pollach @Appeon 22 April, 2021
Hi Walter;

  From your latest screen capture, I see that the runtime files are loaded in the "C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.2703" folder. As long as your <AppName>.XML file's setting is also pointing to that *same* location, the EXE should locate the required runtime DLLs.

  If the runtime folder location is OK, then other causes could be:

1) The runtime DLL's are the wrong bitness that do not match your App EXE's bitness
2) You are still missing some runtime DLLs
  Tip: Try copying the *entire* runtime folder ("C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.2703") folder from your DEV machine to the Deployment PC. 
  If that works, then the problem is either A) The PB Packager was not set to properly select all the required files or B) the manual copy of runtime files was not complete (Check the PB Help under keyword "runtime files" for a detailed list by feature).

Regards ... Chris
Walter Ruaro 22 April, 2021
Screenshot_8.jpg (89KB)

Hello Chris.

Thanks for the prompt response.

As you can see in the attached image, the files are in the folder indicated in the XML

Installing the runtime on each client PC is impossible for us. There are more than 1000 (thousand) positions in our case.

What we had been doing was downloading the necessary dlls in the same application folder.

This was possible when the runtime files included the version number in the name of the same file.

Now for the same application to replace PBVM.dll with the new version is complicated, since that file is always in use.

We thought that with XML we could manage where the runtime dlls were stored.

That is, the application is installed in c: \ application, then we download the runtime in c: \ application \ runtime1 and configure XML to that folder.

With the exit of a new runtime, a new folder called c: \ application \ runtime2 was created, and the XML was modified to this new folder, being able to delete c: \ application \ runtime1 without problems.

Can I explain myself?
Chris Pollach @Appeon 22 April, 2021
Hi Walter;

  Please double check that you installed the PB2019 R3 runtime via the PB Packager's MSI file and that the PB runtime installation via the MSI is in the same folder as the XML file's location. If not, please change the XML file's PB runtime folder to match.

Note: You can eliminate the XML file by ...
  a) Installing the runtime in the same folder as the App's EXE
  b) Removing the XML file and then adding the R3 runtime folder to the 
     O/S's "System Path".

Regards ... Chris
Walter Ruaro 22 April, 2021
Screenshot_7.jpg (73KB)

good morning.

We are testing the migration from PB 2019 R2 to R3

We configure the <application> .xml file, in our case axonico.xml as follows:

<?xml version="1.0" encoding="utf-8" ?>
    <RuntimePath>"c:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime"</RuntimePath>

When executing the application, it gives us an error that PBVM.dll is not in the execution folder.

We understood that now you can download the Runtime libraries in folders other than the application, and that they are not in the Windows PATH.

this is correct?
Windows 10
Database Type:
Microsoft SQL Server
Database Version: