Projektoptionen

[SMO]

Zitat von Bambini:

Kann man die "Debug Konfiguration" wieder los werden ohne in den *.dproj das händisch heraus operieren zu müssen?

Nicht dass ich wüsste. Nervt mich auch. Diese Versionsinfo-Einstellungen benötigen insgesamt eine Überarbeitung.

Zitat von Bambini:

In den "Delphi-Compiler" Konfigurationen klappt das ja recht gut. Die hier geänderten Werte werden Fett dargestellt und nach dem löschen des Eintrags, werden wieder die "Allgemeinen Konfigurationen" geholt. Warum ist das in den Versionsinfos nicht so?

Warum das so ist, lässt sich leicht erklären. Die Optionen, bei denen es schön funktioniert, haben alle ihren eigenen XML-Tag. Zum Beispiel für den Exe-Ausgabepfad:
"<DCC_ExeOutput>.\$(Platform)\$(Config)</DCC_ExeOutput>"
Steht z.B. in der Basiskonfiguration / allgemeine Konfiguration. Wenn dann in einem Kind, z.B. Win32 Release, dieser XML-Tag nicht aufgeführt ist, wird der Wert einfach vom Elternteil geerbt. Ist der Tag im Kind neu definiert (z.B. "<DCC_ExeOutput>.\</DCC_ExeOutput>"), dann überschreibt dieser Wert natürlich den geerbten.

Bei den Versionsinfos ist es nun leider so, dass alle Strings in einen einzigen Tag verwurstet sind:

<VerInfo_Keys>CompanyName=Foo;FileDescription=Bar; FileVersion=1.0.0.0;InternalName=undsoweiter...</VerInfo_Keys>

D.h. es ist unmöglich, in einer abgeleiteten Konfiguration nur einen dieser Werte (z.B. FileVersion) zu überschreiben und den Rest unverändert von der übergeordneten Konfiguration zu erben!


Ein weiteres Ärgernis für mich ist auch die fehlende Synchronisation zwischen der binären FileVersion & ProductVersion und den gleichnamigen Strings.
Eine VersionInfo-Ressource einer DLL/EXE fängt nämlich gewöhnlich mit einem binären 'VS_VERSION_INFO' Block an (siehe TVSFixedFileInfo in Winapi.Windows), der FileVersion, ProductVersion und ein paar Kleinigkeiten mehr enthält. Danach folgt eine 'StringFileInfo' Tabelle, welche die bekannten Name=Wert Stringpaare enthält, darunter eben auch nochmal FileVersion und ProductVersion. Ich finde, es sollte zumindest eine Option geben, diese zu synchronisieren. Denn Delphi macht das auch jetzt schon, aber nur halbherzig:

Wenn man in den Delphi-Optionen "Auto increment build number" einstellt, dann erhöht Delphi die Build-Nummer des Binärwerts automatisch, und setzt den FileVersion String in der Tabelle auf denselben Wert (aber nur, wenn beide vorher identisch waren!).
Benutzt man allerdings statt "Auto increment build number" die Option "Auto generate build number", dann werden nur Release- und Build-Nummer des Binärwerts aktualisiert und der FileVersion String bleibt unverändert!

Wenn man im Windows Explorer die Dateieigenschaften ansieht, bekommt man übrigens als "Dateiversion" den Binärwert zu sehen und als "Produktversion" den ProductVersion String.

Zitat von Bambini:

Und eine andere Frage dazu: Warum gibt es überhaupt verschiedene Versionsinfos? Bei Win32/64 Release/Debug sind das bereits 4.
Bei FMX sind das ein vielfaches mehr.

Nun, es kann durchaus sinnvoll sein, für die verschiedenen Konfigurationen jeweils unabhängige Versionsnummern zu haben. Aber gegen eine Option à la "Diese Versionsinfos global für alle Konfigurationen nutzen" (mit automatischen Update der Release/Build-Nummer) hätte ich auch nichts.