Projektoptionen

[Bambini]

In den Projektoptionen -> Versionsinformationen kann man sehr schön die für die Ziele wie z.B. Debug 32Bit Windows, Debug 64Bit Windows usw.
die Werte setzen. Hat man aber leider versehentlich nicht in dem Ziel für "Alle Konfigurationen" - 32 Bit Windows Plattform sondern in den "Debug Konfigurationen" etwas geändert, ist es vollkommen wurscht, was von nun an in den "Allgemeinen Konfigurationen" geändert wird.

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

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?

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.

[Rollo62]

Ich sehe das als Bug an.
Wenn ich VersionsInfo ändere, dann sollte das auch passieren.

Rollo

[Sherlock]

Es fehlt ein Tool, das bequem die DPROJ auswertet, entkrautet, anzeigt.

Sherlock

[SMO]

Zitat:

Zitat von Bambini (Beitrag 1320975)

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:

Zitat von Bambini (Beitrag 1320975)

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:

Zitat von Bambini (Beitrag 1320975)

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.

[Uwe Raabe]

Zitat:

Zitat von SMO (Beitrag 1321328)

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.

Gibt's da nicht was von Andreas? Set Project Versioninfo dialog

[Der schöne Günther]

Das nutzte ich auch immer :-)
Viel komfortabler als die Standard-Optionen

[SMO]

Zitat:

Zitat von Uwe Raabe (Beitrag 1321333)

Gibt's da nicht was von Andreas? Set Project Versioninfo dialog

Danke für den Tipp, kannte ich noch nicht! :thumb:
Und das obwohl ich schon lange Andreas' IDE Fix Pack benutze...

Das Problem mit der automatischen Aktualisierung/Inkrementierung löst das aber wohl nicht.

[Bambini]

Zitat:

Zitat von SMO (Beitrag 1321328)

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.

Bei den unterschiedlichen Plattformen (Win/Mac/iOS/Android) kann ich das noch nachvollziehen,
aber warum sollte eine iOS Version für den Simulator im Debug Modus eine andere Version tragen als eine Debug Version auf dem 32 Device oder 64 Bit Device? Ich tue mir auch schwer, einen Grund zu finden warum die Version zwischen Debug und Release unterschieden wird.

Eine weiter schlimme Baustelle ist dann noch der Bereitstellungsdialog, also welche Datei wird wann wohin kopiert. Man hat schon einiges an Dialogen gesehen, die Bedienung dieser Maske gehört wahrlich zu der dunkelsten Seite von Delphi. Habe selten so geflucht.:oops:

[Sir Rufo]

Zitat:

Zitat von Bambini (Beitrag 1321387)

Eine weiter schlimme Baustelle ist dann noch der Bereitstellungsdialog, also welche Datei wird wann wohin kopiert. Man hat schon einiges an Dialogen gesehen, die Bedienung dieser Maske gehört wahrlich zu der dunkelsten Seite von Delphi. Habe selten so geflucht.:oops:

Die Oberfläche des Bereitstellungs-Manager ist wahrlich keine Perle.

Aber das was, wann wohin kommt ist eigentlich klar:

Alles kommt dahin, wo man es angegeben hat und zwar sofort bei der Auslieferung (wenn die Option Überschreiben auf immer steht).

Aber Vorsicht, bei voreiligen Schlüssen!

Dateien, die als Remote-Pfad .\assets\internal (Android) bzw. StartUp\Documents\ (alle anderen Plattformen) eingestellt haben, liegen gesichert an diesem Ort. Diese Dateien werden dann aber nochmals beim Start der Anwendung an eine andere Stelle kopiert (wenn es diese Dateien dort noch nicht gibt).

Somit liegen diese Dateien also dann doppelt auf dem Device!

Möchte ich dieses Kopiere mal so ein paar Dateien an andere Orte Verhalten für die Datei foo.txt nicht haben, dann gibt man dort einfach einen Remote-Pfad an, der nicht .\assets\internal bzw. StartUp\Documents\ lautet. ;)