1. Eric Freudenberg
  2. PowerBuilder
  3. Monday, 26 February 2018 10:41 AM UTC

English Text:

Hello Community,

We have two questions about parallel using of the PowerBuilder.
Advance information:

Our company develops two types of software with PowerBuilder. Long-lived ERP software, which is updated on several years and short-lived management software, which is partially updated monthly. Both applications are usually installed on the same customer PC. We are anxious always to develop with the current PowerBuilder version.

As far as we know, the following rule applies when developing with PowerBuilder and installing on customer PCs:
PowerBuilder Build with which we released our software = PowerBuilder build with which the Runtime Kit for the customer PC was created

Example:
- PB2017R1 Product = PB2017R1 Runtime-Kit
- PB2017R2 Product = PB2017R2 Runtime-Kit

If the build deviates from one another (Build Product <> Build Runtime Kit), various, sometimes curious errors can occur.

It is precisely this rule that creates a conflict between our two product types. According to this logic we must install two different runtime-kits simultaneously on the same customer-pc, one for the long-lived product and always a current one for the short-lived. According to our knowledge, it is not possible to use the runtime kit installer to install different versions of the runtime kit. If we try this, the old kit will simply be overwritten.

Now our questions:

  1. What is the best solution for this problem?
    a. Is our knowledge even correct about the rule for using the product release and the runtime kit release?
    b. Is the Runtime Kit is backward compatible?
    c. We have experimented with installing different runtime versions in subdirectories (without using the installer), is this possible? So far, our tests have shown no errors.
    Example:
    • C:\Progs\LONG-LIVED\PB-Runtime
    • C:\Progs\SHORT-LIVED\PB-Runtime
       
  2. What about the developers? To support both types, several PowerBuilder releases would need to be installed on the developer PC. According to Appeon, older versions must be always uninstalled before a new version is installed. Must we create a separate VM for each release to support all our software types in parallel?

Thanks in advance for your answers.
Greetings from Saxony (Germany)

 

German Text:

Hallo Community,

wir haben zwei Fragen zur parallelen Verwendung des PowerBuilders, auf die wir bis jetzt keine eindeutige Antwort erhalten haben bzw. finden konnten.
Vorab folgende Informationen:

Unser Unternehmen entwickelt zwei Arten von Software mit PowerBuilder. Langlebige ERP Software, welche im Takt von teilweise mehreren Jahren geupdatet wird und kurzlebige Verwaltungssoftware, welche teilweise monatlich geupdatet wird. Beide Anwendungen sind üblicherweise auf der gleichen Maschine beim Kunden installiert. Wir sind bestrebt, aufgrund der vielen guten Neuerungen, stehts mit der aktuellen PowerBuilder Version zu entwickeln.

Laut unserem Wissenstand gilt folgende Regel bei der Entwicklung mit PowerBuilder und dem Installieren auf Kunden-PC’s:
PowerBuilder Build beim Release unserer Software = PowerBuilder Build mit dem das Runtime-Kit für den Kunden-PC erstellt wird

Beispiel:
- PB2017R1 Produkt = PB2017R1 Runtime-Kit
- PB2017R2 Produkt = PB2017R2 Runtime-Kit

Weichen die Builds von einander ab (Build Produkt <> Build Runtime-Kit), können diverse, teils kuriose Fehler auftreten.

Genau aus dieser Logik entsteht ein Konflikt durch unsere zwei Produktarten. Es müssten beim Kunden also zwei Runtime-Kits gleichzeitig installiert werden, jeweils eins für das langlebige Produkt und immer ein aktuelles für das Kurzlebige. Laut unserem Wissen ist es gar nicht möglich mittels des Runtime-Kit-Installers verschiedene Versionen des Runtime-Kits zu installieren, versucht man dies, wird das alte Kit einfach überschrieben.
Deswegen nun unsere Fragen:

  1. Wie ist die beste Vorgehensweise bei dieser Problematik?
    1. Stimmt unser Wissen überhaupt über die Logik zum Build des Produktes und dem Build des Runtime-Kits?
    2. Ist das Runtime-Kit inzwischen vielleicht abwährtskompatibel?
    3. Wir haben mit dem Installieren von unterschiedlichen Runtime-Versionen in Unterverzeichnisen experimentiert (ohne die Verwendung des Installers), ist dies problemlos möglich bzw. hat jemand damit schon Erfahrungen gemacht? Bis jetzt haben unsere Tests keine Fehler gezeigt.
      • Beispiel:
        C:\Progs\LONGLIFING\PB-Kit
        C:\Progs\SHORTLIFING\PB-Kit
         
  2. Wie sieht es bei den Entwicklern aus? Für dem Support beider Software-Arten müssten wir unterschiedliche PowerBuilder Releases auf dem Entwickler-PC’s installieren. Laut Appeon sollen aber ältere Versionen stehts deinstalliert werden, bevor eine neue Version installiert wird. Müssen wir hier für jedes Release extra eine VM anlegen um alle unserer Softwarearten parallel zu supporten?

Vielen Dank im Voraus für eure Antworten.
Grüße aus Sachsen (Deutschland)

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Monday, 26 February 2018 15:17 PM UTC
  2. PowerBuilder
  3. # 1

Hi Eric;

   Yes, the R1 & R2 PBVM run-times must be kept separate at all costs as all the DLL's have the same name. You can either install the associated PBVM in each PB App EXE's folder or do what you did ans install the MSI run-time into two separate root folders. Make sure however that these PBVM's are not in your deployed PC's System Path. Instead, create a .BAT file to launch an App's EXE and  add the appropriate PBVM to its System Path in the .BAT file.

  The IDE's are not compatible on the same PC - thus, separate PC's and/or the use of VM's in the key here for R1 & R2 coexistence.

HTH

Regards ... Chris

Comment
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Monday, 26 February 2018 15:27 PM UTC
  2. PowerBuilder
  3. # 2

Greetings, Eric

For runtime environment I suggest installing the PB runtime files in the same folder as the application using them. This way your app can find the .DLL versions it needs no matter how strange the Path may be configured.

Installing both PB 2017 and PB2017 R2 development environments on same machine is NOT straightforward.

When installing PB 2017R2, the installer aborts with error message "You must de-install PB 2017 before installing PB 2017 R2".

BUT - in case your development machines use virtual machines (e.g. Hyper-V), then you can co-exist the PB versions on same computer by installing them on different VM on that computer. At least, that is how I understand the installation process for PB 2017. Warning: I haven't tried this myself, so anyone - please chime in if you have practical experience with such side-by-side install of PB IDEs. 

 

Best regards from Switzerland (in a couple of days from Denmark) ;.)

HTH /Michael

Comment
There are no comments made yet.
Eric Freudenberg Accepted Answer Pending Moderation
  1. Tuesday, 27 February 2018 08:11 AM UTC
  2. PowerBuilder
  3. # 3

Hello Community,

Thank you Chris and Michael for your answers. These have already brought us a lot further.

Our approach would be the following now:
We create a Runtime Install Kit (PBDK) with the "Appeon PowerBuilder Runtime Packager", but we do not deliver this.
Then we extract the pure Runtime files from the PBDK and deliver these pure files with our own program installer.
It will be installed in a subfolder of the corresponding program (C:\Progs\MyApp\PBDK), then we will refer to this subfolder via the registry, so that our application finds the PBDK files (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MYAPP; Key:"Path").

Two questions:
1. Must be any files of the PBDK registered with Windows?
Of course, the PBDK contains *.DLL files but also *.OCX files, which actually have to be registered with "regsrv32.exe".
Are we wrong here, or must registered some files, if so which ones?

2. Is the method using the subfolder and referenced by registry a safe way?
We've been using this method successfully for years on external libraries, but never with PBDK files.
We need to know if it's a safe method. Our programs coordinate large amounts of money, the functionality must be guaranteed.

Thanks in advance for your answers.
Greetings from Saxony (Germany)

Comment
  1. Chris Pollach @Appeon
  2. Tuesday, 27 February 2018 16:18 PM UTC
Hi Eric;



1) Yes, some PBVM DLL's must be registered in the GAC. For example the one that handles the SaveAs (Excel!) command. You can see the GAC listing by a) using the DOS command "gacutil /l > c:\temp\GAC_List.txt".



In the GAC_List file, scroll down to the Sybase section (note that Appeon has not changed that yet on PB 2017 to Appeon.DataWindow. .... , for example:



  Sybase.DataWindow.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc0f66dd9541b3da, processorArchitecture=x86

  Sybase.DataWindow.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc0f66dd9541b3da, processorArchitecture=x86

  Sybase.DataWindow.Interop, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc0f66dd9541b3da, processorArchitecture=x86

  Sybase.DataWindow.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc0f66dd9541b3da, processorArchitecture=x86

  etc ...

 



2) Yes, the subfolder approach is one of the best approaches. The other - as I mentioned before - is using a BAT file to start the PB App but set the local environment's System Path specifically for each APP.



HTH



Regards ... Chris



 



 



 

  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.