Runtime-Packages, visual inheritance, Updaten der Runtime-Packages ohne exe-Update

[Uwe Raabe]

Zitat von RSE:

Ich weiß allerdings nicht, ob die Checkbox "Laufzeit-Packages verwenden" bewirkt, dass ich alle dort bereits eingetragenen Packages als Laufzeit-Packages mitliefern müsste. Zweites Problem: Der untere Bereich ist bei Packages grau.

Wenn du die CheckBox anklickst, kannst du das Feld editieren. Du schreibst da nur die Packages rein, die du als Runtime-Packages mitliefern willst. Dazu kommen noch die, die von den Runtime-Packages required werden (z.B. RTL, VCL).

Die Units aus den Packages, die du dynamisch laden willst, dürfen im Source nicht verwendet werden.

[hanspeter]

Zusätzlich zu den verwendeten bpl gibt es noch versteckte BPL Abhängigkeiten. Das führt dazu, dass ein Delphiprogramm noch eine Reihe bpl beim Start verlangt,
die im Programm selbst garnicht verwendet werden.
In meinem Projekt waren das so um die 70 bis 80 bpl, die zusätzlich mitgeliefert werden mussten.
Fehlende oder geänderte bpl merkt man erst beim Kunden, da hier erst die isolierte Umgebung vorhanden ist.
Also vor der Auslieferung in einer delphifreien VM testen, ob das Programm startet.
Dann beten, das kein weiteres Delphiprogramm auf dem gleichen Rechner bpl benötigt. Das muss nicht mal mit unterschiedlichen Delphi-Versionen compiliert sein.
Das bpl Konzept ist antiquiert und verursacht nur Ärger.
Wenn wirklich Modular, dann entweder dll und Interface oder Com-Technologie.
Eine große Exe und Schluss oder eine kleine Exe und 80 bis 90 bpl die versioniert überwacht und updatet werden müssen, was ist besser?
Ich habe runtime bpl zwischenzeitlich aus allen Projekten wieder herausgeworfen, da Nutzen und zusätzlicher Aufwand in keinem Verhältnis stehen.

Gruß
Peter

[Uwe Raabe]

Zitat von hanspeter:

Zusätzlich zu den verwendeten bpl gibt es noch versteckte BPL Abhängigkeiten. Das führt dazu, dass ein Delphiprogramm noch eine Reihe bpl beim Start verlangt,
die im Programm selbst garnicht verwendet werden.

..zumindest nicht direkt.

Zitat von hanspeter:

In meinem Projekt waren das so um die 70 bis 80 bpl, die zusätzlich mitgeliefert werden mussten.
Fehlende oder geänderte bpl merkt man erst beim Kunden, da hier erst die isolierte Umgebung vorhanden ist.
Also vor der Auslieferung in einer delphifreien VM testen, ob das Programm startet.

Oder man schaut nach dem Compilieren mal unter Projekt - Info auf die Liste "Verwendete Packages".

Zitat von hanspeter:

Dann beten, das kein weiteres Delphiprogramm auf dem gleichen Rechner bpl benötigt. Das muss nicht mal mit unterschiedlichen Delphi-Versionen compiliert sein.

Grundsätzlich sollten BPLs, die mit unterschiedlichen Delphi-Versionen compiliert sind, auch unterschiedliche Namen haben. Ansonsten könnte man ja auch nicht verschiedene Delphi-Versionen gleichzeitig auf dem Rechner haben. Wer es dann ganz ordentlich machen will, gibt der BPL dann auch noch die eigene Versionsnnummer im Dateinamen mit. Bei neueren Delphi-Versionen helfen da die Einträge für LIB-Suffix und LIB-Version. Im Zweifelsfall packt man die benötigten Packages in das Verzeichnis, wo auch die EXE liegt.

Zitat von hanspeter:

Das bpl Konzept ist antiquiert und verursacht nur Ärger.
Wenn wirklich Modular, dann entweder dll und Interface oder Com-Technologie.

DLLs sind sicher nicht besser als BPLs was unterschiedliche Versionen auf dem Rechner betrifft. Und COM unter OSX könnte auch etwas haarig werden. Delphi-Packages funktionieren aber unter allen Zielplattformen. Antiquiert im Sinne von "gibt es schon sehr lange" - ja, aber immerhin nutzt .NET dieses Konzept ja ziemlich intensiv.

Zitat von hanspeter:

Eine große Exe und Schluss oder eine kleine Exe und 80 bis 90 bpl die versioniert überwacht und updatet werden müssen, was ist besser?
Ich habe runtime bpl zwischenzeitlich aus allen Projekten wieder herausgeworfen, da Nutzen und zusätzlicher Aufwand in keinem Verhältnis stehen.

Wie jede Technologie muss man wissen was man tut und Aufwand und Nutzen gegeneinander abwägen. Es ist sicher kein brauchbarer Weg um die EXE-Größe zu verkleinern oder den Update-Aufwand zu minimieren. Wenn es aber wie in diesem Fall um visual inheritance geht, sind dynamische Packages ein durchaus gangbarerer Weg. Mit anderen Ansätzen wird die Lösung sicher nicht leichter.

Es gibt übrigens noch ein anderes Beispiel, wo das Package-Konzept erfolgreich für einen modularen, dynamischen Aufbau verwendet wird: FinalBuilder!

[RSE]

Vielen Dank für das Aufweisen der Stolperfallen. Mein Ziel ist es nicht, die Größe des Gesamtprogramms zu verringern, sondern zu modularisieren und Module zur Programmlaufzeit updaten zu können.

Habe ich denn die 3 verschiedenen Arten, Packages einzubinden, oben korrekt wiedergegeben?

Wieso kann ich ein Package nicht statisch in ein anderes linken?

Würden sich die vielen (80-90???) benötigten BPLs nicht als Designtime-Packages einbinden lassen (so wie in eine "normale" exe)?