Grund für $LIBVERSION Parameter in *.dpk Dateien?

[MaBuSE]

Zitat von MaBuSE:

Die Frage ist wozu $LIBVERSION?

Hallo,
ich hab mal ein wenig rumprobiert Die Frage kann ich nun selbst beantworten.

Bei der Verwendung der Laufzeit Packages gibt es wie bei den *.dll Dateien (ist ja im Grunde dasselbe) die so genannte dll - Hölle.

Beispiel 1:

Wir haben 2 Anwendungen, die dasselbe Package verwenden. (A1.exe, A2.exe und P.bpl)

Wie kompilieren das Package und die 2 Anwendungen -> alles Super.
Ich installiere die 3 Dateien beim Kunden und programmiere weiter an den neuen Funktionen der 2 Anwendungen.

Nun muss eine Änderung am Package gemacht werden, da in Anwendung 1 ein Bug enthalten ist.
Dieser Bug betrifft aber nur Anwendung 1. Anwendung 2 hat schon neue Funktionalität, die noch nicht ausgeliefert werden soll.

Also kompiliere ich das Package und die Anwendung 1, liefere es meinem Kunden aus und ...

MIST!

Anwendung 1 funktioniert mit dem Package Version 2 super, aber Anwendung 1 nicht.
Anwendung 1 funktioniert nur mit dem alten Package.

Dieses Szenario ist bekannt.
Das ist auch der Grund, warum viele keine Laufzeit Packages einsetzen.

So nun zu $LIBVERSION :

Beispiel2:

Wir haben 2 Anwendungen, die dasselbe Package verwenden. (A1, A2 und P)
Aber im Package haben wir $LIBVERSION auf '1.0.0' gesetzt.
Also wieder alles kompilieren und ausliefern. (A1.exe, A2.exe und P.bpl.1.0.0)

Wir ändern das Package und passen auch $LIBVERSION an ('1.0.1')
Nach dem Kompilieren des Packages und der Anwendung 1 liefern wir folgende Dateien aus:
A1.exe und P.bpl.1.0.1

Beim Kunden liegen nun folgende Dateien im Verzeichnis:

• A1.exe
• A2.exe
• P.bpl.1.0.0
• P.bpl.1.0.1

Die Anwendung 1 benutzt das neue Package die Anwendung 2 das Alte.

SUPER. Es gibt kein Problem.

Beim Kompilieren der Anwendungen wird immer die neuste Version eingebunden.
Die requires Sektion von Packages muss auch nicht angepasst werden, da die *.dcp Datei ja ohne Versionsnummer ist. (p.dcp)

Schade nur, dass man das $LIBVERSION Tag von Hand pflegen muss. Man hätte es auch an die VERSIONINFO knüpfen können.

Nachteil:
Wenn nun 20 Änderungen des Packages ausgeliefert wurden würden in unserem Beispiel 22 Dateien im Verzeichnis liegen.
Mann muss also genau Buch führen, wann man die alten Versionen nicht mehr benötigt.
Komplizierter wird das bei 50 (teilweise voneinander abhänigigen) Packages und z. B. 20 *.exe Dateien.
Es macht also Sinn, bei einem Major Release (z.B. aus 1.2.17 wird 2.0.0) alle Package und Anwendungen zu kompilieren und die Alten komplett zu entsorgen.

Vorteil:
Es gibt keine Probleme mit falschen Packageversionen.

Fazit:
Eine gute Sache.

Also $LIBPREFIX zum kennzeichnen von Laufzeit und Designtime Packages,
$LIBSUFFIX zum kennzeichnen der Delphi Version (150 -> Delphi XE),
$LIBVERSION zum kennzeichnen der Version des Packages um Versionskonflikten zur Laufzeit aus dem Weg zu gehen.

Danke für's Lesen

mfg
MaBuSE

[Sir Rufo]

[QUOTE=MaBuSE;1076456]

Zitat von MaBuSE:

Nachteil:
Wenn nun 20 Änderungen des Packages ausgeliefert wurden würden in unserem Beispiel 22 Dateien im Verzeichnis liegen.
Mann muss also genau Buch führen, wann man die alten Versionen nicht mehr benötigt.
Komplizierter wird das bei 50 (teilweise voneinander abhänigigen) Packages und z. B. 20 *.exe Dateien.
Es macht also Sinn, bei einem Major Release (z.B. aus 1.2.17 wird 2.0.0) alle Package und Anwendungen zu kompilieren und die Alten komplett zu entsorgen.

Da es sich ja um "sharedfiles" handelt, sollte man die im Setup auch mit dem Flag "sharedfile" versehen.
Dadurch werden die diese Dateien erst dann deinstalliert, wenn keine andere Installation diese mehr benötigt.

Somit ist es nur wichtig vernünftige Setups auszuliefern, denn diese kümmern sich um das Aufräumen selber.