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:
- 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
- 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:
- Wie ist die beste Vorgehensweise bei dieser Problematik?
- Stimmt unser Wissen überhaupt über die Logik zum Build des Produktes und dem Build des Runtime-Kits?
- Ist das Runtime-Kit inzwischen vielleicht abwährtskompatibel?
- 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
- Beispiel:
- 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)
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