Delphi 10.2 Tokyo Release 3 verfügbar

[Uwe Raabe]

Zitat von SearchBot:

Gerade erst vor etwa 4 Wochen mit einer größeren SSD hatte ich mir die Zeit genommen, stundenlang die .2 installiert und endlich wieder für 1 Projekt die Komponenten zum Laufen bekommen - jetzt muss ich schon wieder alles in die Tonne treten und von vorne anfangen??

Bei dem Update bleiben ja die Komponenten und Einstellungen erhalten (solange du das nicht gezielt abwählst). Es besteht also kein Grund, alles in die Tonne zu treten und von vorne anzufangen.

Wenn du auf Nummer sicher gehen willst, dann exportiere deine Einstellungen vorher mit der migrationtool.exe aus dem Delphi bin-Verzeichnis.

[blawen]

Zitat von Uwe Raabe:

Zitat von SearchBot:

Gerade erst vor etwa 4 Wochen mit einer größeren SSD hatte ich mir die Zeit genommen, stundenlang die .2 installiert und endlich wieder für 1 Projekt die Komponenten zum Laufen bekommen - jetzt muss ich schon wieder alles in die Tonne treten und von vorne anfangen??

Bei dem Update bleiben ja die Komponenten und Einstellungen erhalten (solange du das nicht gezielt abwählst). Es besteht also kein Grund, alles in die Tonne zu treten und von vorne anzufangen.

Wenn du auf Nummer sicher gehen willst, dann exportiere deine Einstellungen vorher mit der migrationtool.exe aus dem Delphi bin-Verzeichnis.

Kann ich nur bestätigen. Ich habe das Update eingespielt und danach ohne irgendwelche Eingriffe weiterarbeiten können

[mensch72]

"...stelle mir dabei vor, für ein Windows-Update müsste ich Windows komplett deinstallieren..."
das musst du dir nicht vorstellen, das ist bei Win10 die Realität 1511,1609,1703,1709, usw. ist immer eine Neuinstallation des WinVerzeichnisses und MS schafft es recht gut alle sauber installierten Programme funktionsfähig beizubehalten.
(ABER: frag mal die D2007 Nutzer, denen MS bei jeder Win10 Updateneuinstallation immer ein paar "private" .NET Dateien irgendwo unter WinDir fehlen(is nicht MS Schuld, die hätte da nie hingehört)

Also macht Emba es doch richtig, und wie man liest klappt es auch bei vielen ganz gut mit dem beibehalten der installierten Komponenten.
Ich mache aus Prinzp keine Delphiupdates mit drüberinstallieren oder deinstallieren+installieren... ich installiere jede Delphiversion per VM frisch in ein ebenso frisches aktuelles Windows.
Ja das ist&macht Arbeit und braucht etwas Festplattenplatz und Zeit. Windows incl. aktueller Updates, neues Delphi incl. passendem Java, dann Androidstudio fürs MobileSDK/NDK, Delphi für Nutzung von AndroidSDK/NDK, IOS/OSX & Linux(FMXlinux&CrossVCL) konfigurieren. Jedi, TMS, UniDac und IntraWeb neu installieren, nochmal die WinUpdates aktualisieren... VM zwischendurch per Snapshot und zum Schluss KOMPLETT SICHERN(+packen und archivieren).

Das dauert trotz Übung zeitlich einen ganzen Tag, auch wenn es großteils nebenbei läuft und man nur abundzu manuell was eingeben/auswählen/bestätigen oder starten muss.
Vorteil ist, das man es freiwillig StepByStep dokumentiert... es ist gut zu wissen das Drüberinstallieren per Auto-Uninstall+Install möglich ist, aber Worstcase nützt mir das Wissen um den sicheren Weg zu einer wieder voll nutzbaren sauberen Neuinstallation auf Dauer mehr.
(nix ist schlimmer wie gewachsene Delphi-Installationen mit zig installierten und funktionierenden Zusatz-Komponenten ohne das noch jemand weiß, wie und wo diese Komponenten neu installiert werden können/müssen)

[Uwe Raabe]

Zitat von mensch72:

Jedi, TMS, UniDac und IntraWeb neu installieren

Wie schön wäre es, wenn alle Komponentenhersteller ein einheitliches, automatisierbares Setup hätten

[Lemmy]

Zitat von Uwe Raabe:

Zitat von mensch72:

Jedi, TMS, UniDac und IntraWeb neu installieren

Wie schön wäre es, wenn alle Komponentenhersteller ein einheitliches, automatisierbares Setup hätten

Ich denke das wäre ein erreichbares Ziel, wenn Embarcadero hier deutliche Vorgaben machen würde, wie was zu installieren ist. Oder vielleicht gleich die Komponenteninstallation in die IDE überarbeiten und durch ein flexibles System ersetzen würde...

Grüße

[himitsu]

Zitat von Lemmy:

Oder vielleicht gleich die Komponenteninstallation in die IDE überarbeiten und durch ein flexibles System ersetzen würde...

GetIt mit alternativen Quellen?

Aber auch da scheint es keine einheitlichen Install.Vorgaben zu geben .. jeder macht es anders, aber wenigstens über ein gemeinsames Portal.

[Uwe Raabe]

Zitat von himitsu:

Aber auch da scheint es keine einheitlichen Install.Vorgaben zu geben .. jeder macht es anders, aber wenigstens über ein gemeinsames Portal.

Ein einheitliches Verfahren, einheitliche Nomenklatur wäre mir da viel wichtiger.

[Lemmy]

Zitat von himitsu:

Zitat von Lemmy:

Oder vielleicht gleich die Komponenteninstallation in die IDE überarbeiten und durch ein flexibles System ersetzen würde...

GetIt mit alternativen Quellen?

Aber auch da scheint es keine einheitlichen Install.Vorgaben zu geben .. jeder macht es anders, aber wenigstens über ein gemeinsames Portal.

nein, eher wie bei Visual Studio, dass ich eine bestimmte Komponente(nversion) in ein Projekt dazu lade/linke und wenn ich ne neue Version der IDE installiere, ich einfach das Projekt lade und die notwendigen Libs dann automatisch heruntergeladen und bereit gestellt werden.

[sh17]

jaaa, projektabhängige Komponenten, das wäre Klasse, so kann man auch mal umstandslos ältere Stände auschecken. Zum anderen würde ich mir von den Komponentenherstellern, zumindest optional, ZIP-Archive ihrer Komponenten wünschen. Ich mag dieses rumgefusche in meinem System nicht. Alles wird von jedem angepasst und irgendwo hin installiert/verteilt

[himitsu]

Zitat von Lemmy:

nein, eher wie bei Visual Studio, dass ich eine bestimmte Komponente(nversion) in ein Projekt dazu lade/linke und wenn ich ne neue Version der IDE installiere, ich einfach das Projekt lade und die notwendigen Libs dann automatisch heruntergeladen und bereit gestellt werden.

Aber dafür brauchst du eine/mehrere zentrale Quellen, wo dann die verlinkten Projekte/Komponenten geladen werden können.
z.B. auch eine eigene Quelle, für die Komponenten der eigenen Firma, welche dann bei allen Kollegen verfügbar sind.

Projektabhängig geht schon (halb), denn die geladenen/diableten Packages werden auch in den DPROJ gepspeichert, auch wenn das IMHO in der aktuellen Umsetzung eher grauenhaft, als nützlich ist.