• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • PBRuntime: determine used version with .GetVersionName (from GetContextService)

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved PBRuntime: determine used version with .GetVersionName (from GetContextService)

  1. Issue
0
Votes
Undo
  1. Pieter Coene
    Pieter Coene
  2. PowerBuilder
  3. Thursday, 31 May 2018 07:55 AM UTC

Hi,

we are using the GetContextService(...) method and GetVersionName() to determine which version our current executable is running. We use this check if there is a new PBRuntime available in our own database (we save the runtime as a blob in our database), if there is, we download the runtime. We used this method to upgrade from PB 07 to PB09, to PB11 and then to PB 12.5 (yes, we go a long way)

We are deploying our products with the new PB 2017 now, the GetVersionName() returns '17.0.0' for both PB 2017 and PB2017 R2. To bad for us (i was hoping the R2 would return 17.0.1), this way we see no difference in the pbruntime. Gladly we just starting upgrading our clients using the R2 only. But, if the R3 comes out, we probably want to upgrade to this version. I assume the GetVersionName() will also return '17.0.0'. So is there a better way to detect which exact version of PBRuntime the executable is running (without checking the properties of a fixed dll, which name changes every PB version)?

Greetz
Pieter

 

  1. TIME
Mobile deployment using MSSQL Server
Our remote windows server does not allow FTP, how ...
Responses (2)
Ken Guo @Appeon
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Thursday, 31 May 2018 09:18 AM UTC
  2. PowerBuilder
  3. # 1

Hi Pieter，

 

Thanks for reporting this problem and for your valuable suggestion.

We'll transfer this enhancement to our product team for consideration.

 

Currently, are you able to work around this issue using GetEnvironment method?

For example:

 

string ls_version

environment env

GetEnvironment(env)

ls_version = "Version: "+ string(env.pbmajorrevision) ls_version += "." + string(env.pbminorrevision) ls_version += "." + string(env.pbfixesrevision) ls_version += " Build: " + string(env.pbbuildnumber) MessageBox("PowerBuilder Version", ls_version)

 

Best Regards,

Ken

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 31 May 2018 13:22 PM UTC
  2. PowerBuilder
  3. # 2

Hi Pieter;

         FYI: I have been discussing this very issue with the Engineering Team a few months ago. Many of our customers have various Apps in various revision stages (GA, R2 & R3, etc) and need to be able to use the right IDE for the same revision based PB App. My suggestion (like yours) is that the PB Run-time return the proper minor version number as well. So 17.0.0 for GA, 17.0.2 for R2 and 17.0.3 for R3, etc would be prudent IMHO.

       However, the problem does not stop there. Some PB developers will need to have various "revisions" of the IDE installed on the same PC because of their mix of PB App related versions. Thus, the PB IDE & Runtime DLL's need to be similarly numbered as well. So for example PBVM170.dll (GA), PBVM172,dll (R2) and PBVM173.dll (R3), etc.. This numbering of course is not currently being used when a revision is released. Thus having multiple IDE revisions on the same PC is not possible (reliable).

      Another significant problem is that some DLL's in the SHARE folder do not have any numbering. For example the LIBxxxxx.dll's, NETxxxxx, etc. This also needs to be addressed if different PB IDE revisions are to be supported on the same PC and for the PB Community where keeping deployment run-times by revision is also a must.

The best advice I can give you for the moment is to make sure that you kep your IDE's on separate machines and/or VM's and that your App's check the BUILD # at run-time (system-to-system controls) to ensure that the correct revision of the PB run-time is found at App start-up.

HTH

Regards ... Chris

Comment
Pieter Coene
  1. Pieter Coene
  2. Friday, 1 June 2018 07:47 AM UTC
Hi Chris (and Ken),



my thoughts exactly, although the DLL versioning in the name is not a problem for me. For deployment of our apps, we distribute the correct 'dlls' in the same folder as our App (so in deployment there is no sharing dlls at all). Although i never understood why they added the 'major' versioning in the name of the dll while windows had a built-in versioning system. Of course, this is historicly, so not the 'fault' of Appeon...



As for the PB Runtime check in our Apps, we only check the first three 'levels' (majorrevision, minorrevision and fixesrevision) to determine the PB Runtime version so we would have to add the build number as well. This does not fit in our internal versioning database so we have to make soms changes to be able to do this (but this is our problem of course).



Greetz

Pieter

  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.