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

[MaBuSE]

Hallo,
da in der Beschreibung dieses Bereiches "Benutzung und/oder Weiterentwicklung von Komponenten" steht, schreibe ich meine Frage hier rein, obwohl es nichts mit GUI zu tun hat. ;-)

Bei der Erstellung von Packages gibt es in der *.dpk Datei die Möglichkeit einen Parameter $LIBVERSION zu setzen.

Delphi-Quellcode:

{$LIBVERSION '1.0'}

Was diese Option macht, verstehe ich.

In der Delphi Hilfe steht:

Fügt dem Ausgabedateinamen eine zweite Dateinamenserweiterung nach der Erweiterung .bpl hinzu.
Durch die Angabe 2.1.3 für Package1 wird beispielsweise Package1.bpl.2.1.3 generiert.

Aber: Wozu braucht man diese Option?

Borland/CodeGear/Embarcadero verwenden die Option $LIBSUFFIX um die (Delphi-)Version vor das .bpl zu setzen. (

Delphi-Quellcode:

{$LIBSUFFIX '150'}

)

Kennt jemand die Antwort?

Danke
MaBuSE

[Uwe Raabe]

Nehmen wir an, wir erstellen ein Runtime-Package MyPackage und das dazugehörige Designtime-Package MyPackageDesign. Das Design-Package required das Runtime-Package.

Erstellt man das Package nun für verschiedene (Delphi-)Versionen, dann müsste man die DPK-Dateien und alles was dazu gehört jedesmal umbenennen (schlecht für die Versionsverwaltung) und bei jedem Umbenennen das requires im Design-Package ändern.

Verwendet man nun das LibSuffix (z.B. "150"), wird aus einer MyPackage.dpk eine MyPackage150.bpl und eine MyPackage.dcp. Damit kann das requires so bleiben, die Projektdateien behalten ihren Namen und die einzige Änderung ist der Eintrag für das LibSuffix.

Mach das Leben deutlich einfacher.

[MaBuSE]

Zitat:

Zitat von Uwe Raabe (Beitrag 1076431)

... Verwendet man nun das LibSuffix (z.B. "150"), ... Mach das Leben deutlich einfacher.

Das ist mir bekannt. Das verwende ich schon seit Jahren.

Aber das war ja auch nicht die Frager ;-)

Die Frage ist wozu $LIBVERSION ?

mfg
MaBuSE

[MaBuSE]

Zitat:

Zitat von MaBuSE (Beitrag 1076435)

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

Delphi-Quellcode:

$LIBVERSION

:

Beispiel2:

Wir haben 2 Anwendungen, die dasselbe Package verwenden. (A1, A2 und P)
Aber im Package haben wir

Delphi-Quellcode:

$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

Delphi-Quellcode:

$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

Delphi-Quellcode:

$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

Delphi-Quellcode:

$LIBPREFIX

zum kennzeichnen von Laufzeit und Designtime Packages,

Delphi-Quellcode:

$LIBSUFFIX

zum kennzeichnen der Delphi Version (150 -> Delphi XE),

Delphi-Quellcode:

$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:

Zitat von MaBuSE (Beitrag 1076435)

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.

[jbg]

Zitat:

Zitat von MaBuSE (Beitrag 1076428)

Wozu braucht man diese Option?

$LIBVERSION wurde für Linux (Kylix) benötigt, da dort alle SharedObjects (DLL) mit so einer Versionsnummer im Dateinamen verwendet werden. Unter Windows sieht man solche versionierte Dateien nicht so oft. Microsoft zur Lösung dieses Problems side-by-side assemblies (C:\Windows\winsxs) erfunden, bei dem die unterschiedlichen Versionen in unterschiedlichen Ordnern liegen und somit den selben Dateinamen behalten können. Referenziert wird die richtige Version der DLLs dabei über einen Eintrag in der Manifest-Ressource/Datei.

[MaBuSE]

@Sir Rufo: Danke für die Info.

Zitat:

Zitat von jbg (Beitrag 1076507)

Zitat:

Zitat von MaBuSE (Beitrag 1076428)

Wozu braucht man diese Option?

$LIBVERSION wurde für Linux (Kylix) benötigt, ...

Danke für die Info. Das würde erklären, warum ich es noch nicht gebraucht habe ;-)
Wir verwenden keine Laufzeitpackages um Problemen aus dem Weg zu gehen.

Zitat:

Zitat von jbg (Beitrag 1076507)

Microsoft zur Lösung dieses Problems side-by-side assemblies (C:\Windows\winsxs) erfunden, bei dem die unterschiedlichen Versionen in unterschiedlichen Ordnern liegen und somit den selben Dateinamen behalten können. Referenziert wird die richtige Version der DLLs dabei über einen Eintrag in der Manifest-Ressource/Datei.

Der Mechanismus ist mir bekannt, auch wenn ich ihn selbst noch nie bewusst benutzt habe.
Funktioniert das auch bei *.bpl Dateien?
Im Grunde sind das ja auch nur *.dll Dateien, die nur eine gewisse Struktur bei den definierten Prozeduren/Funktionen haben. Mal von den Unterschieden wegen Memorymanager, Parameterübergaben ... abgesehen.