Vielfältige Probleme bei der Migration von Projekten zu neuer RAD Studio Version

[PeterPanino]

Embarcadero RAD Studio wäre ein perfektes Entwicklungssystem, wenn es nicht immer diese scheußlichen Probleme bei der Migration von Projekten in eine neu RAD Studio Version gäbe! Das fängt schon damit an, dass die gesamte VCL inkompatibel zur neuen Version ist, auch wenn in der neuen Version nur Teile der VCL erneuert wurden! Formulare können nicht mehr geöffnet werden, weil sich Eigenschaften geändert haben, und vieles mehr. Ich glaube, dass Embarcadero damit auch viel Geld verliert, weil Entwickler den Umstieg auf eine neue RAD Studio wegen dieser Migrationsprobleme scheuen. Zumindest könnte Embarcadero im eigenen Interesse Hilfen bereitstellen, um die Migration zu erleichtern.

Wie geht ihr mit den Problemen bei der Migration zu einer neuen RAD Studio Version um?

[Bernhard Geyer]

Zitat:

Zitat von PeterPanino (Beitrag 1194838)

Embarcadero RAD Studio wäre ein perfektes Entwicklungssystem, wenn es nicht immer diese scheußlichen Probleme bei der Migration von Projekten in eine neu RAD Studio Version gäbe! Das fängt schon damit an, dass die gesamte VCL inkompatibel zur neuen Version ist, auch wenn in der neuen Version nur Teile der VCL erneuert wurden! Formulare können nicht mehr geöffnet werden, weil sich Eigenschaften geändert haben, und vieles mehr. Ich glaube, dass Embarcadero damit auch viel Geld verliert, weil Entwickler den Umstieg auf eine neue RAD Studio wegen dieser Migrationsprobleme scheuen. Zumindest könnte Embarcadero im eigenen Interesse Hilfen bereitstellen, um die Migration zu erleichtern.

Kann ich nicht bestätigen. Meistens sind es 3th-Party-Kompos die man nicht mehr in neuen Versionen bekommt die Probleme verursachen.
Die VCL von Emba ist eigentlich zu 99% Kompatible solange man nicht fehler bei Stringtyp-Annahmen (1 Zeichen = 1 Byte)

Zitat:

Zitat von PeterPanino (Beitrag 1194838)

Wie geht ihr mit den Problemen bei der Migration zu einer neuen RAD Studio Version um?

Im EDN gibts einige Artikel die Portierungsanleitungen liefern die sich z.B. den Probemen mit Unicode (D2009 und neuer) oder den erweiterten RTTI (XE?) oder 64-Bit (integer wächst wie auch bei C++/Java/.NET nicht mehr)widmen

[mjustin]

Zitat:

Zitat von PeterPanino (Beitrag 1194838)

Zumindest könnte Embarcadero im eigenen Interesse Hilfen bereitstellen, um die Migration zu erleichtern.

Ja, zum Beispiel indem man die VCL Version eines Projektes unabhängig von der IDE Version machen würde. Dazu bräuchte die IDE nur die älteren VCL Libraries (Packages) zu enthalten. Und in der Projektdatei wird dann hinterlegt, dass das Projekt die Delphi 2010/XE/XE2 oder XE3 VCL benutzt. Dann könnte man in der neuen IDE das alte Projekt öffnen, und vor dem Speichern die VCL Version umstellen (was im Idealfall dann eine Prüfung durch den Compiler auslösen würde). Oder mit der alten VCL noch solange in der neuen IDE arbeiten bis man alles für den Wechsel klar hat (Drittanbieterkomponenten).

Aber das alles geht nicht so einfach (allein schon weil sich das DCU Format von Version zu Version ändert).

[Bernhard Geyer]

Zitat:

Zitat von mjustin (Beitrag 1194841)

Ja, zum Beispiel indem man die VCL Version eines Projektes unabhängig von der IDE Version machen würde. Dazu bräuchte die IDE nur die älteren VCL Libraries (Packages) zu enthalten.

Und wie sollte dann eine D7 dann die Sprach-Extensions aus der Erweiterten RTTI verstehen? oder den Unicode-String-Typ? Oder NativeInt (ok, das wäre das einfachste)?
Die VCL ist wie bei MS die MFC oder bei Java die entsprechenden Versionen. In eine Richtung (Neu IDE versteht alte Frameworkversionen), aber umgekehrt geht das auch dort nicht. Ein .NET-Programm das reichlich von den neuen .NET 4.0-Möglichkeiten nutzen zieht wird man nicht unter VS.NET 2002 zum laufen bekommen.

Zitat:

Zitat von mjustin (Beitrag 1194841)

Und in der Projektdatei wird dann hinterlegt, dass das Projekt die Delphi 2010/XE/XE2 oder XE3 VCL benutzt.

Wie gesagt. Wird schon allein an den neuen Sprachfeaturen scheitern. Und sowas selbst nur in den Möglichkeiten wie VS.NET oder Intellij IDEA zu realisieren kostet schon einige Mannjahre die mann dann nicht mehr für neue Features zur verfügung hat.

Zitat:

Zitat von mjustin (Beitrag 1194841)

Dann könnte man in der neuen IDE das alte Projekt öffnen, und vor dem Speichern die VCL Version umstellen (was im Idealfall dann eine Prüfung durch den Compiler auslösen würde). Oder mit der alten VCL noch solange in der neuen IDE arbeiten bis man alles für den Wechsel klar hat (Drittanbieterkomponenten).

Die vorgehensweise ist so:

1, Neue Version von 3th-Party-Komponenten in alter IDE-Version installieren und dort erst Lauffähigkeit wieder herstellen/Testen
2, Entsprechend eigene Inc-Dateien oder Basiskomponenten soweit anpassen das sie auch mit neuen Delphi-Versionen lauffähig sind (Stichwort Unicode/NativeInt/...)
3, und zum Schluss dann die Projekte umstellen. Hierbei bis zur vollständigen lauffähigkeit immer noch alles Forms mit alten Delphi-Versione editieren damit kein neuen Properties in die DFM-Datei aufgenommen werden.

Zitat:

Zitat von mjustin (Beitrag 1194841)

Aber das alles geht nicht so einfach (allein schon weil sich das DCU Format von Version zu Version ändert).

Was in Delphi das DCU-Format ist, ist z.B. in .NET die Abhänigkeit gegenüber der Frameworkversion. Hatte gerade erst denn Fall das eine mit integriert Komponente nur mit .NET 2.0 (bzw. 3.5) lauffähig war aber es mittlerweilen PC's gibt die nur .NET 4.0 installiert haben.

[mjustin]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1194843)

Zitat:

Zitat von mjustin (Beitrag 1194841)

Ja, zum Beispiel indem man die VCL Version eines Projektes unabhängig von der IDE Version machen würde. Dazu bräuchte die IDE nur die älteren VCL Libraries (Packages) zu enthalten.

Und wie sollte dann eine D7 dann die Sprach-Extensions aus der Erweiterten RTTI verstehen?

Natürlich geht das so nur abwärtskompatibel, also aus der neueren IDE heraus, daher schrub ich "Dazu bräuchte die IDE nur die älteren VCL Libraries (Packages) zu enthalten." - mehr zu erwarten wäre leicht utopisch.

[Bernhard Geyer]

Zitat:

Zitat von mjustin (Beitrag 1194847)

Natürlich geht das so nur abwärtskompatibel, also aus der neueren IDE heraus, daher schrub ich "Dazu bräuchte die IDE nur die älteren VCL Libraries (Packages) zu enthalten." - mehr zu erwarten wäre leicht utopisch.

Ok. Hab es missverstanden.
Aber auch dies bedeutet Mehraufwand. So müsste die IDE an sich dann auch die alten VCL-Versionen in der IDE verstehen das diese ja als Designtime-Packages geladen werden. Der entsprechenden Runtime-Package-Manager müsste gegen die unterschiedlichen VCL-Versionen programmiert werden und per Bridge/Fassage diese dann an die restliche IDE welche gegen die neueste VCL-Version compiliert ist, verfügbar machen. Wird sicherlich auch ein paar Mannmonate/jahre arbeit bedeuten.

[Uwe Raabe]

Zitat:

Zitat von PeterPanino (Beitrag 1194838)

Wie geht ihr mit den Problemen bei der Migration zu einer neuen RAD Studio Version um?

Ehrlich gesagt, konnte ich keine gravierenden Probleme bei der Migration feststellen. In den meisten Fällen muss man sogar bei Drittanbieter-Komponenten lediglich ein paar IFDEFs in einer Include-Datei anpassen und dann läuft das einfach. Natürlich kann man dann meistens nicht mehr einfach zurück, aber das will man ja auch eigentlich gar nicht.

Einzig bei D2007 -> D2009 gab es ein paar Probleme mit unsauber programmierten Libraries. In allen anderen Fällen war es kaum mehr als Projekt öffnen und compilieren.