Installationsformen von Delphi/Optimierung per Batch-Datei

**jbg**

Die Frage sei erlaubt, ob nicht alles was funktional über das simple RunImage bei D5 hinaus geht, wirklich gebraucht wird und wie schnell sich ein D10.3 auf Basis einer reinen Dateikopieraktion installieren ließe.

Also unser Delphi 2009 installiert sich in ca. 30 Sekunden ohne Delphi-Installer über eine selbst geschriebene install.bat. Danach noch eine "Delphi-Components" install.bat ausführen, die die IDE konfiguriert, alle Komponenten kompiliert und in der IDE registriert (ca. 40 Sekunden auf SSD).
Man hat somit in unter 2 Minuten eine vollständige Delphi 2009 Installation.

Bevor wir diese Batchdateien hatten, war man ein bis zwei Tage beschäftigt die Komponenten in der richtigen Reihenfolge zu installieren und ich war dann immer derjenige der das kaputtkonfigurierte Delphi wieder zum laufen bringen musste. Die Zeit spare ich mir.

Für neuer Delphi Versionen bräuchte man sicherlich um einiges länger, da die Gigabytes erstmal übers Netzwerk auf die Platte entpackt werden müssten. Aber den Installer würde es mit Sicherheit noch bei weitem schlagen.

**Codehunter**

Zitat von jbg:

Für neuer Delphi Versionen bräuchte man sicherlich um einiges länger, da die Gigabytes erstmal übers Netzwerk auf die Platte entpackt werden müssten. Aber den Installer würde es mit Sicherheit noch bei weitem schlagen.

Ich habe nicht unbedingt den Eindruck dass die aktuellen Delphi-Installer großartig komprimiert wären. Die installierten Dateien sind nur unwesentlich größer als der komplette Download. Womöglich enthält der Installer aber auch Teile, die bei meinen Pro-Installationen gar nicht entpackt werden. In dem Fall nenne ich diese Art Installer gerne "Einer für alles, alles für die Katz".

Wenn man sich anschaut, was ein installiertes Delphi eigentlich ist: Ein Teil im Programme-x86-Ordner, ein Teil im User-Ordner und ein Stückchen Registry. Kann man eigentlich gut per Batch installieren.

Insofern würde ich mir wünschen, Emba würde in den nächsten 25 Jahren wieder mehr Augenmerk auf den Installer und dessen Qualität legen.

**jaenicke**

Zitat von jbg:

Also unser Delphi 2009 installiert sich in ca. 30 Sekunden ohne Delphi-Installer über eine selbst geschriebene install.bat. Danach noch eine "Delphi-Components" install.bat ausführen, die die IDE konfiguriert, alle Komponenten kompiliert und in der IDE registriert (ca. 40 Sekunden auf SSD).

Solange der Server erreichbar ist, hatten wir mit dem aktuellen GetIt-Installer auch keine Probleme. Es dauert deutlich länger, klar, das dauerte glaube ich 10 Minuten oder so, aber das hängt ja auch vom Installationsumfang ab.

Aber das Installationsskript für alle Komponenten kann man wirklich nur jedem wärmstens empfehlen, ja. Das ist ja nicht besonders schwierig, nur etwas Aufwand, aber dafür läuft dann wirklich auf jedem Rechner alles gleich und ohne manuelles Zutun. Wobei ich vermute, dass du das Skript schöner gelöst hast als ich (ich schreibe einfach einiges vorkonfiguriert via Templates in die Registry).

Nur die JEDIs müssen bei uns vorher manuell mit dem Installer installiert werden. Wobei... da sollte sich doch ein "unattended" Schalter relativ einfach einbauen lassen... wir klicken ja eh nur durch ohne etwas zu ändern. Das habe ich mir gleich mal notiert, das schaue ich mal an, wenn ich die Zeit finde.

**dummzeuch**

Zitat von Codehunter:

Ich habe nicht unbedingt den Eindruck dass die aktuellen Delphi-Installer großartig komprimiert wären. Die installierten Dateien sind nur unwesentlich größer als der komplette Download. Womöglich enthält der Installer aber auch Teile, die bei meinen Pro-Installationen gar nicht entpackt werden. In dem Fall nenne ich diese Art Installer gerne "Einer für alles, alles für die Katz".

Der Installer (also das ISO) enthält alle Dateien für die Architect-Version und auch alle Sprachen und ein paar zusätzliche Tools. Wenn Du also nicht die Architect-Version hast, ist das nicht verwunderlich.

Zitat von Codehunter:

Wenn man sich anschaut, was ein installiertes Delphi eigentlich ist: Ein Teil im Programme-x86-Ordner, ein Teil im User-Ordner und ein Stückchen Registry. Kann man eigentlich gut per Batch installieren.

Wenn die 7z-Dateien nicht password-geschützt wären, hätte ich das vielleicht schon mal implementiert. Vielleicht könnte man aber auch einfach eine installierte Version als Basis nehmen und diese clonen. Wenn ich mal igendwann viel Zeit habe ... (also niemals, denn immer dann, wenn man gerade Stunden damit verschwendet den Installer laufen zu lassen, hat man eigentlich gar keine Zeit).

**jaenicke**

Zitat von DieDolly:

Zitat:

Danach noch eine "Delphi-Components" install.bat ausführen, die die IDE konfiguriert, alle Komponenten kompiliert und in der IDE registriert

Sowas interessiert mich. Wie sieht der Inhalt so einer BADatei aus?
Ich muss das immer manuell machen. Alle Komponenten bereinigen, kompilieren, installieren und meine exportierten Einstellungen importieren.

Ich habe Registry-Templates, in denen die Delphiversion ersetzt wird und die dann per reg importiert werden. Das könnte man natürlich auch mit einer kleinen Anwendung direkt machen.
So setze ich auch die Pfade, aber natürlich nur die Werte, die auch wichtig sind (Bibliothekspfad, ...).

Danach kann ich dann die Packages mit den gemeinsamen Units und Komponenten einfach mit msbuild erstellen. Installiert werden die Packages auch einfach per Registry.

Es gibt in den JEDI-Quelltexten auch direkte Möglichkeiten der Package-Installation, aber den Aufwand wollte ich nicht betreiben, auch wenn es schöner gewesen wäre...

**jbg**

Zitat von jaenicke:

Nur die JEDIs müssen bei uns vorher manuell mit dem Installer installiert werden.

Die habe ich in einem eigenen Package (zwei, da Designtime und Runtime getrennt sind) neu verpackt. Das reduziert die Anzahl der Packages die von der IDE geladen werden müssen, womit das Starten einen ticken schneller geht.

Natürlich musste man bei allen Komponenten die Packages einmalig entsprechend auswendig konfigurieren (z.B. gleiches BPL/DCP/DCU Ausgabeverzeichnis, $STRINGCHECKS OFF, ...). Das ist aber jetzt nur dann mit Aufwand verbunden, wenn mal wieder ein Komponenten-Update bevorsteht. Da wir aber Delphi 2009 nutzen, kommt das bei kommerziellen Komponenten selten bis gar nicht mehr vor. Und OpenSource Komponenten/Projekte sind meist einfacher einzubinden, da kein Installer erstmal alles "zerschießt".

Zusammengestrichen sieht die Batchdatei so aus (Kommentare, Echo, Error-Handling entfernt). Ist also nur ein einfacher MSBUILD Ausruf mit ein paar selbst geschrieben Tools, die die Registry und Environment.proj Datei aktualisieren.

markieren

Code:

			msbuild /nologo /t:build /p:Config=Debug /p:ComponentGenPackage=true Components2009.groupproj

bin\ComponentInstaller Components2009.groupproj /RegisterDesignPackages /RegisterPaths

bin\ExpertInstaller.exe IDEPlugins\IDEFixPack.dll /PRELOAD:IDEPlugins\IDEFixPackStartup.bpl IDEPlugins\DDevExtensions2009.dll IDEPlugins\JclProjectAnalysisExpertDLL120.dll IDEPlugins\DfmCheck2009.bpl

**himitsu**

Also es gibt immernoch keinen Weg, aus einer Batch/FinalBuilder diese environment.proj zu aktualisieren, ohne dafür die BDS zu starten?
z.B. irgendein Tool von Emba aufzurufen

Schlimm ist auch, dass alle Imports, auch so Essentielle, mit einer Condition versehen sind
und es dann auch keine Fehlermeldung oder wenigstens Logmeldung gibt, die angibt, welche Imports nicht ausgeführt wurden.

Zumindestens via /preprocess kann man sich von MSBuild teilweise sagen lassen, was es macht, aber
* die DPROJ selbst zu parsen ist pervers bis fast unmöglich
* schön wöre es, wenn man das Ergebnis des letzten Schrittes bekommen könnte, direkt vor dem Ausführen
* leider stoppt /preprocess wohl schon nach dem "Evaluate imports and properties" ->

https://learn.microsoft.com/en-us/vi...w?view=vs-2022

**Uwe Raabe**

Zitat von himitsu:

Also es gibt immernoch keinen Weg, aus einer Batch/FinalBuilder diese environment.proj zu aktualisieren, ohne dafür die BDS zu starten?

Den gibt es tatsächlich: Solange man es nicht mit dem Parameter dnsef bzw. donotsetenvfile unterbindet, macht die GetItCmd.exe das auch. Ein unkritischer Befehl wie GetItCmd -l=Hurz sollte genügen.

**himitsu**

Boar geil.

OK, -h sollte man auch nicht benutzen, aber -l= tut es auch (ohne die "nix gefunden"-Fehlermeldung).

markieren

Code:

			cd /d "%ProjectPath%"

call "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\rsvars.bat"

"%BDS%\bin\GetItCmd.exe" -l=

"%FrameworkDir%\MSBuild.exe" /nologo /target:Build /property:Platform=Win32 /property:Config=Debug "%ProjectFile%"

Dann kann ich nun endlich den alten Code aus meinem FinalBuilderScript rauswerfen.
* HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Environment Variables mit dr reg.exe in einen Datei exportieren
* vorne ein [xyz] einfügen
* dann mit der INI-Funktion des FinalBuilders lesen und das als Umbegungsvariablen im FB setzen (könnte man auch pervers als Parameter an die MSBuild-Action übergeben)

* die MSBuild-Actions will ich eh demnächt durch manuelle Aufrufe der MSBuild.exe ersetzen (Run DOS Command / BatchFile)
* dann kann ich die GetItCmd und RSVars vor der MSBuild ausführen und muß nichts mehr manuell parsen

* jetzt muß ich nur noch das perverse Parsen der rsvars.bat ersetzen
In einer Batch kann man ja einfach CALL und sie ausführen lassen.
Aber desetzte Variablen einer Batch als Umgebungsvariable zurück in den FinalBuilder, geht nicht.
Ich lese die Datei "böse" als INI ein, Replace den Batch-Schrott und setzte es per VBScript als Umgebungsvariablen im FinalBuilder. (andere fügen ECHO an solche Dateien an und Parsen die Ausgabe dann im FinalBuilder)