Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
You need to be logged in to view a user's profile.
View Replies (6)

Resolved Missing shared folder in pb 2019 r3 beta ?

  1. Misc
0
Votes
Undo
  1. Miguel Leeuwe
    Miguel Leeuwe
  2. Beta Testing
  3. Sunday, 4 October 2020 02:21 AM UTC

Hi,

I've installed PB2019 R3 beta on a clean machine.

I've created a small machine code executable (with a traditional project object, not the new C/S one) and it fails for not finding in the first place "PBVM.DLL" (not even the name is correct as it should be "PBVM19x.DLL", but that's not the problem).

The problem is that I cannot find the shared dll's anywhere on none of my 2 disks. I can run the application fine from the PB IDE.

Is this something new or is there something wrong?

See the 2 attached images.

regards

 

 

Attachments (2)
almost empty shared folder.png almost empty shared folder.png
pb2019r3 works without shared dlls.png pb2019r3 works without shared dlls.png
Compiling and Running apps with Beta3
Oleobject NOT work in the NEW PB (Beta)
Accepted Answer
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Sunday, 4 October 2020 02:54 AM UTC
  2. Beta Testing
  3. # Permalink

The folder is there, just not in the system path.

The application runtime DLL files will be in a folder under C:\Program Files (x86)\Appeon even if the rest of it is installed to a different drive.

 

Comment
Load more comments
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Sunday, 4 October 2020 15:46 PM UTC
FWIW: I have always and I would strongly recommend (if not there already) implementing System-To-System controls, to check that all the run-time pieces are there and of the correct version. This feature in my frameworks has saved my deloyed apps from improper execution many times.

Regards... Chris
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Tuesday, 6 October 2020 17:38 PM UTC
This change Roland pointed out is related to the decoupling of the PB IDE and runtime so now the IDE can target multiple versions of runtime: https://docs.appeon.com/pb2019r3/whats_new/Separating_Runtime_from_IDE.html

  1. Helpful
mike S
  1. mike S
  2. Tuesday, 6 October 2020 18:07 PM UTC
This also appears to be the comprehensive list of ALL runtime files and ONLY runtime files that need to be deployed?!



In the past you had to hunt and peck to find the files listed in a bunch of different help file pages (and you would always miss some and/or get the wrong version). Now they are be in one spot so it will be super fast/easy and complete way of getting the runtime files to deploy.
  1. Helpful
There are no comments made yet.
Responses (6)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 6 October 2020 19:50 PM UTC
  2. Beta Testing
  3. # 1

Hi Mike;

  FYI... no XML file and the App runs great on the user's PC deployed from the PC Server.

Regards ... Chris

Comment
mike S
  1. mike S
  2. Tuesday, 6 October 2020 19:55 PM UTC
didn't say the xml file was required.



i said that the exe will read it. and use it if it is there. you can edit the xml file to 'repoint' the directory. that will allow you to test it.



  1. Helpful
There are no comments made yet.
mike S
mike S Accepted Answer Pending Moderation
  1. Tuesday, 6 October 2020 18:35 PM UTC
  2. Beta Testing
  3. # 2

The xml file that is created when you create a PB exe will point to the runtime directory.

On startup, this xml file is read by your exe and the exe will changes ITS runtime path to include the runtime directory. 

So if you run your app from the same pc as where it was built, then it will run correctly.   If this did not work for you, then you should check to see if the xml file was created.

 

That also means you can change the xml file to point to wherever you install the runtime dlls.  I don't think that is a good practice (IMO you should always copy the dlls to the directory where your application is installed), but it does work.

Comment
Load more comments
mike S
  1. mike S
  2. Tuesday, 6 October 2020 19:26 PM UTC
HI Chris,

The exe does read the xml file. try it.





  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 6 October 2020 19:33 PM UTC
Hi Mike;

The XML file on the User's PC is built by the PCL Service when the App is launched by the PB Launcher and is *not* downloaded from the PC Server. The launcher is the one that knows where the PB runtime is and then amends the local System Path as the PB App is being started. Just like a BAT file would do. The PB App EXE does not read the XML file for this, its just trusting the "local" system Path.

If you have forced a download of the XML file from the PC Server because you added it in your PC "Project", try deleting the XML file in your User AppData area and then launch the PB App. It will run OK without it.

;-)
  1. Helpful
mike S
  1. mike S
  2. Tuesday, 6 October 2020 19:49 PM UTC
i haven't looked at powerclient much less set it up. just building my application and running it.



the exe DOES read the xml file

  1. Helpful
There are no comments made yet.
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 6 October 2020 12:43 PM UTC
  2. Beta Testing
  3. # 3

Without the version number in the runtime dll files, when the next major version comes along we won't be able to have multiple major version runtimes in the same folder.

If we have more than one application and don't want to upgrade them all at the same time, we will have to remove the runtime folder from the system path and either put the runtimes in the application folder or use the App Path setting in the registry to tell the program where the runtimes are.

 

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 6 October 2020 13:25 PM UTC
Very correct!

We were already distributing the runtime on a per application basis. Having all of the dlls of different versions in the same folder is not such a good idea anyway: In the past I've had problems with the rich text's dlls having the same name but being different versions in different runtimes. Therefore failing when an older one had been overwritten with a newer one.

  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 6 October 2020 15:03 PM UTC
That is easy to design for. IMHO. I leave the PB run-times in their own separate install folders. Then at App runtime, I use a BAT file to append the correct PB version run-time folder to the App;s System Path. Then I launch the PB App EXE from the BAT file.
  1. Helpful
There are no comments made yet.
Olan Knight
Olan Knight Accepted Answer Pending Moderation
  1. Monday, 5 October 2020 20:18 PM UTC
  2. Beta Testing
  3. # 4

I'm wondering is dropping the version manes from the DLLs is the intended direction for the future of the PB DLLs.

Off the top of my head this seems like a bad plan for multiple reasons, but maybe I'm being paranoid for no reason.

IF this is the direction Appeon is headed, does anyone know WHY this is the chosen path?


Thank You!

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 6 October 2020 12:03 PM UTC
I guess it's needed for the new feature of now having decoupled the IDE from the runtime versions.

You can now choose the runtime version at compile time, so I guess the DLLs should no longer include any version information.

Not a problem for me, I always get the Version information from PBVM.dll with some API, made available by Roland Smith in this object: https://topwizprogramming.com/freecode_osversion.html

regards
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 6 October 2020 12:07 PM UTC


Example of how I use n_osversion::



n_osversion ln_osver

ls_pbvmname = ln_osver.of_PBVMName()

If ln_osver.of_GetFileVersionInfo(ls_pbvmname) Then

ls_FixedFileVersion = trim(ln_osver.fixedFileVersion)

if Integer(left(ls_FixedFileVersion, 2)) >= 17 then

// Appeon 2017 or higher, We use this in u_dw for example.

ib_Appeon = TRUE

end if

end if
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 6 October 2020 12:19 PM UTC
Here's what we do to check on the fileversion information:



If ln_osver.of_GetFileVersionInfo(ls_fullPath ) Then

ls_FileVersion = trim(ln_osver.fixedFileVersion)

ls_FileVersion = mid(ls_FileVersion, 1, lastpos(ls_FileVersion, ".") - 1 ) // we only compare the first 3 digits, the last one is to distinguish builds

ls_DBVersion = trim(ls_DBVersion)

ls_DBVersion = mid(ls_DBVersion, 1, len(ls_FileVersion) )

if ls_DBVersion <> ls_FileVersion then

Messagebox("Please contact ... Support", "You have an incorrect version of .... on your PC.~r~n~r~nPlease contact ... support on ..... immediately.", StopSign!, Ok!)

gnv_app.of_debug("You have an incorrect version of ... on your PC. Please contact ... support on ... immediately. Product version: " +&

ls_FileVersion + " System setting: " + ls_DBVersion, TRUE ) // true to "force" the loggin

return FALSE

end if

End If

  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Sunday, 4 October 2020 03:32 AM UTC
  2. Beta Testing
  3. # 5

Edited:

What I said previously about the "dll name not being correct", is incorrect: In R3 the PBVM190.dll is indeed called "PBVM.DLL" without any version information. This might be a good direction of things, but it means I have to modify my programs (not much work) as we look for the file information of the PBVM190.dll to check if the customer has the correct runtimes on his pc. (we simply copy them and add the folder dynamically to the path, so no installation of any runtime).

 After realising this, now I found the runtimes in:

C:\>dir pbvm.dll /s
Volume in drive C is WinSSD
Volume Serial Number is F607-773B

Directory of C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.0.2556
10/09/2020 00:32 7,028,304 pbvm.dll
1 File(s) 7,028,304 bytes
Directory of C:\Program Files (x86)\Appeon\Common\PowerBuilder\Runtime 19.2.0.2556\x64
10/09/2020 00:32 8,024,656 pbvm.dll
1 File(s) 8,024,656 bytes

regards

Comment
Load more comments
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 6 October 2020 14:59 PM UTC
That is a good technique Miguel and very important to establish a valid runtime.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Tuesday, 6 October 2020 15:18 PM UTC
Yes, before, we would "physically" edit the path on (almost) each user machine, so we ended up having some users sometimes pointing to 'old' runtime versions for applications build with newer pb versions.

Now we first use GetEnvironmentVariable() to get the current path, then pre-pend (is that a word?) our runtime path to it and set it with SetEnvironmentVariable(). The beauty of this, is that the change in path only affects the current session that you are running. The path in windows is not changed.

We don't do ANY runtime installation, we simply copy all we need to a subfolder called SHARED at the same level of the EXE.

It's a big improvement on how things worked before.

The only thing that changes with the new powerbuilder runtimes, is that when testing an executable, BEFORE we could just test an EXE by running it without above mentioned SHARED subfolder, since the runtimes would be in the path anyway due to powerbuilder being installed on my PC.

Now this is no longer the case, but I'll just set add the path myself in my windows.

regards
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Tuesday, 6 October 2020 17:48 PM UTC
It's the same when using a BAT file, the System Path is a "local" path to the App and not the one registered to the Windows O/S. It only lives within the execution of the BAT file.
  1. Helpful
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.