Wie schwierig ist es, ein Projekt von Delphi 7 nach Delphi XE zu migrieren?

Question

Unser Unternehmen hat eine Software, die seit über 10 Jahren in der Entwicklung ist, also sind da einige wirklich veraltete Sachen drin. Es ist immer noch ziemlich funktionell und alles, aber ich sehe die neuen Funktionen von Delphi XE und es macht mir Lust zu wechseln. Das Problem ist, dass der Quellcode selbst über 300 MB an .pas-Dateien umfasst (insgesamt 1 GB mit Komponenten usw.).

Wir verwenden benutzerdefinierte Komponenten, altes Jvcl-Zeug und das neueste Devexpress.

Mit welchen Schwierigkeiten muss ich rechnen, wenn ich von Delphi 7 auf Delphi XE umsteigen möchte?

Ich danke Ihnen.

Answer 1

Das einzige wirkliche Problem ist die Umwandlung in Unicode. Sie sollten lernen, wie die Unicode-Unterstützung in Delphi implementiert ist - beginnen Sie mit Marco Cantu Weißbuch: Delphi und Unicode

Es ist unmöglich, den Arbeitsaufwand für die Umstellung alter Anwendungen auf Unicode abzuschätzen, ohne den tatsächlichen Code zu kennen. Wenn Sie Zeichenkettentypen auf die übliche Weise verwenden, wäre die Konvertierung einfach. Alle Low-Level-Tricks mit Stringtypen (wie das Speichern von Binärdaten in Strings) sind jetzt veraltet und der entsprechende Code sollte neu geschrieben werden.

Answer 2

Einige kleine Tools lassen sich entweder ohne Änderungen migrieren, oder es sind nur einige Unicode-Korrekturen erforderlich, um sie zum Laufen zu bringen.

Wenn Ihre Codebasis jedoch so umfangreich ist, wie Sie es beschreiben, sollten Sie sich nicht vollständig auf das verlassen, was Ihnen hier jemand sagt. Besorgen Sie sich einfach eine Kopie von XE und laden Sie den Code. Schauen Sie, auf welche Probleme Sie stoßen, um ein Gefühl für den Aufwand zu bekommen, den Sie betreiben werden.

Im Moment habe ich meinen gesamten Code auf XE portiert (auch alte Projekte). Ich verwende so oft wie möglich dieselben Bibliotheken. Sobald ich also die meisten davon konvertiert habe, war die "Portierung" von Anwendungen von Delphi 7 auf Unicode-Delphi in der Regel nur eine sich wiederholende Aufgabe, um entweder mit aktualisierten Schnittstellen in den Bibliotheken umzugehen oder Compilerfehler und Warnungen zu beheben.

Die häufigsten Fehler, auf die ich gestoßen bin:

• Unicode-Zeug. Das wird 90% der Zeit in Anspruch nehmen. Es ist ärgerlich, wenn der Code eine Menge von Low-Level-String-Handling, aber die meisten der Probleme können leicht behoben werden, indem Sie einige Typecasts.

• der Compiler meckert, wenn Sie c in ['a'..'z'] . Sie sollten Folgendes verwenden CharInSet() für Unicode-Zeichenfolgen.

• Wenn Sie ShortDateFormat festlegen, erhalten Sie eine Compilerwarnung, dass Sie stattdessen FormatSettings.ShortDateFormat verwenden sollten. In neuem Code ist das eine gute Idee. Wenn Sie portieren, ignorieren Sie es zunächst einfach, wenn Sie einfach loslegen wollen.

Außerdem werden Sie wahrscheinlich Ihre Bibliotheken von Drittanbietern auf neuere Versionen aktualisieren, so dass Sie diese nicht selbst portieren müssen. Es ist nicht ungewöhnlich, dass diese ihre Schnittstellen oder Arbeitsweisen geändert haben, so würde ich einige Testversionen von denen herunterladen, um zu sehen, was geändert wurde.

Answer 3

In einem Ihrer Antwortkommentare erwähnten Sie SQL... Unterstützt Ihre Datenbank Unicode? Wenn nicht, könnte Ihnen eine Menge Arbeit bevorstehen. Möglicherweise müssen Sie Datenbanken im laufenden Betrieb konvertieren oder ein Konvertierungstool für Ihre Benutzer erstellen. Möglicherweise müssen Sie die Datenbank aktualisieren oder sogar auf eine andere Datenbank umsteigen. DBISAM ist beispielsweise nicht unicode-fähig, aber der Hersteller bietet ElevateDB an, die es kann. Die Umstellung ist nicht trivial. Und einige andere Bibliotheken wie Hyperstring, die größtenteils in Assembler geschrieben sind, sind ein weiterer wunder Punkt.

Answer 4

Ich habe ziemlich viele dieser Umwandlungen vorgenommen.

Sie sollten sich darauf vorbereiten, indem Sie Ihre aktuelle Codebasis testbar machen. Vorzugsweise mit automatisierten Einheitstests, aber zumindest mit einem guten Plan für Endbenutzertests.

Dann sollten Sie den größten Teil einplanen: die Unicode-Konvertierung sowohl für Ihre Anwendung als auch für Ihre Datenbank.

Schließlich gibt es noch weniger wichtige, aber potenziell sehr zeitaufwendige Aspekte:

• Wenn Sie BDE verwenden, ist es jetzt an der Zeit, es loszuwerden
• Delphi XE ist strenger als Delphi 7
• Bibliotheksversionen von Drittanbietern, die einige Versionen nach oben schießen und in der Regel weit weniger abwärtskompatibel sind als die VCL

Wenn Sie sie portiert haben, ist es an der Zeit, etwas zu ändern: Da Sie die gesamte Codebasis gesehen haben, wissen Sie jetzt, wo Ihre Schwachstellen liegen, so dass Sie damit beginnen können, sie zu überarbeiten und eine bessere Anwendung als zuvor zu erhalten.

Answer 5

Mein Projekt umfasst etwa eine Million Codezeilen und ich habe kürzlich von CB9 auf XE portiert. Um den Arbeitsaufwand zu reduzieren, habe ich zunächst viel umgeschrieben, damit ich nicht mehr von Komponentenpaketen von Drittanbietern abhängig bin. Dann habe ich alles, was mit Strings zu tun hat (Unicode), sorgfältig überprüft und bin erst dann zu XE übergegangen. Die Vorbereitung war eine Menge Arbeit, die eigentliche Portierung war relativ einfach.