Meine Meinung zu dem eigentlichen Problem.
Von Delphi auf irgend eine andere Sprache umzustellen, ist für größere Projekte absoluter Unsinn und Geldverbrennung.
Aus meiner früheren Praxis als freiberuflicher Software Entwickler,kenne ich einige Firmen,
die von Dos auf Windows umstellen wollten und versucht haben, vorhanden Code anzupassen.
An der Umstellung von Dos auf Windows sind sie gescheitert und letztendlich auch Pleite gegangen.
Mit dem Wechseln z.B. zu C# ist man bemüht die Struktur und den Code aufwandsarm umzustellen, obwohl in C# effektivere Lösungen,möglich wären.
Zum Schluss hat man ein in C# geschriebenes Delphi Programm.
Der Anwender merkt wenig Unterschied.
Eher meckert er - Früher war es schneller.
Ich hatte in einem vorhergehenden Beitrag geschrieben, dass ich mit XE2 zunehmend Probleme beim Debug habe.
Inzwischen habe ich weiter gesucht und meine, daß das Problem alle Delphi Versionen haben könnten.
Microsoft hat wohl die Aufruf/Ladefunktionen für
Dll geändert.
Das ist nicht mehr mit Delphi BPLs kompatibel und führt zu fast endlosen Nachladeschleifen.
Ich selbst gehe davon aus, dass Microsoft das Problem früher oder später löst.
Damit kann ich bei XE2 bleiben.(Notfalls in einer VM unter Windows 7)
Zu eurem Problem wäre eine Mittelweg denkbar.
RemObjects bietet ein Framwork an, welches Delphi und Dot.Net Applikationen synchronisiert.
So beschreibt Remobjects die Funktion:
Zitat:
Hydra ist ein Anwendungsframework, mit dem Entwickler modulare Anwendungen erstellen können,
die verwalteten (.NET) und nicht verwalteten ("nativen" Delphi) Code im selben Projekt kombinieren und so eine nahtlose Benutzerschnittstelle schaffen.
Link
Hydra
Meine Vorstellung wäre den vorhandenen Delphicode so zu lassen wie er ist und nur noch Bug Support zu vorzunehmen.
Neu hinzu kommende Funktionalität dann in Dot.Net und über Hydra als Plugin einbinden.