Migration von VB6 zu VB.NET

31/12/2009 - 15:54 von Oliver Dietz | Report spam
Hallo zusammen,

wie habt ihr den Umstieg von VB6 auf VB.NET mit euren (größeren) Anwendungen
gemacht?

Bei uns geht es darum eine VB6-MDI-Anwendung mit einigen Jahren
Entwicklungsarbeit auf VB.NET zu portieren. Eine komplette
Neuimplementierung auf einen Schritt ist wohl kaum machbar - das würde
einige Monate dauern - mal ganz davon abgesehen, dass man dann eine neue
Anwendung (mit Kinderkrankheiten) hat, die erstmal getestet werden muss und
mit halbfertigen Produkten kein Geld verdient wird ...

Perfekt wàre, wenn man das MDI-Parent unter Dotnet neu entwickelt und alle
anderen Forms erstmal in VB6 lassen könnte. Also Hauptanwendung in .NET und
VB6-Forms in einer DLL. Die einzelnen VB6-Forms werden dann nach und nach zu
.NET übernommen. Das scheint aber leider nicht möglich zu sein - selbst bei
einem normelen modalen Fenster gibt es schon Probleme beim Wechsel in eine
andere Anwendung und wieder zurück.

Von Microsoft wird ja der "VB6 Interop Forms Toolkit" angeboten. Der kann
laut Beschreibung aber keine MDI-Childs bereitstellen (ausser über den Umweg
von UserControls) und die Anwendung bliebe erstmal weiterhin in VB6.

Diese Idee sieht verlockend aus und wàre optimal für uns:
http://www.codeproject.com/KB/vb-in...inNET.aspx

Leider gibt es hier ein paar ernste Problemchen z.B. funktioniert die Tab-
und Enter-Taste in der VB6-Form nicht.


Was empfehlt ihr in einem solchen Fall?


Vielen Dank für eure Tipps,
Oliver



__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4732 (20091231) __________

E-Mail wurde geprüft mit ESET NOD32 Antivirus.

http://www.eset.com
 

Lesen sie die antworten

#1 Armin Zingler
31/12/2009 - 16:23 | Warnen spam
Oliver Dietz schrieb:
Hallo zusammen,

wie habt ihr den Umstieg von VB6 auf VB.NET mit euren (größeren) Anwendungen
gemacht?

Bei uns geht es darum eine VB6-MDI-Anwendung mit einigen Jahren
Entwicklungsarbeit auf VB.NET zu portieren. Eine komplette
Neuimplementierung auf einen Schritt ist wohl kaum machbar - das würde
einige Monate dauern - mal ganz davon abgesehen, dass man dann eine neue
Anwendung (mit Kinderkrankheiten) hat, die erstmal getestet werden muss und
mit halbfertigen Produkten kein Geld verdient wird ...

Perfekt wàre, wenn man das MDI-Parent unter Dotnet neu entwickelt und alle
anderen Forms erstmal in VB6 lassen könnte. Also Hauptanwendung in .NET und
VB6-Forms in einer DLL. Die einzelnen VB6-Forms werden dann nach und nach zu
..NET übernommen. Das scheint aber leider nicht möglich zu sein - selbst bei
einem normelen modalen Fenster gibt es schon Probleme beim Wechsel in eine
andere Anwendung und wieder zurück.

Von Microsoft wird ja der "VB6 Interop Forms Toolkit" angeboten. Der kann
laut Beschreibung aber keine MDI-Childs bereitstellen (ausser über den Umweg
von UserControls) und die Anwendung bliebe erstmal weiterhin in VB6.

Diese Idee sieht verlockend aus und wàre optimal für uns:
http://www.codeproject.com/KB/vb-in...inNET.aspx

Leider gibt es hier ein paar ernste Problemchen z.B. funktioniert die Tab-
und Enter-Taste in der VB6-Form nicht.


Was empfehlt ihr in einem solchen Fall?



"Kommt ganz darauf an." ;-)

Darüber könnte ich ein ganzes Liedchen tràllern - oder erstmal die Kurzversion:
Ich würde erst einmal die nicht-UI-Komponenten portieren! Also erst einmal
ein neues Fundament schaffen.

Wenn sie unter VB6 einigermaßen sauber sind, kann man sie durchaus durch den
Upgrade-Wizard jagen und hat dann noch etwas manuelle Anpassung vor sich.
Andernfalls wird's eben mehr Aufwand, und dann sollte man sich überlegen, es
gleich neu zu schreiben. Auch eine Überlegung ist, ob man, nach dem Upgrade-Wizard,
nur die 1:1-Portierung vollzieht, also daraus eine COM-gerechte Assembly macht,
die funktionieren wie die VB6-dll, oder ob und in welchem Umfang man gleich die
neuen Möglichkeiten von VB.Net und des Frameworks nutzt und voll ausschöpft.

Den UI-Kram würde ich ganz zum Schluß in Angriff nehmen. Viel Spaß bei der
Anpassung von Grafik- und Druckprogrammierung! ;)

Erfahrungsgemàß - ich hab ein Projekt bestehend aus einer Exe mit ~150 Formularen
und 20 DLLs mehrfach (2002, 2003, 2005, 2008) nach .Net versucht, zu portieren,
um die Ecken und Kanten für eine reelle Portierung (die nie mehr eintreten wird...)
herauszufinden - gibt es dabei diverse unerwarteter Stolpersteine. So werden manchmal
Verweise nicht gefunden oder tlbimp funktioniert nicht wie gewünscht etc pp. Ich
hab jetzt nicht parat, was das alles war. Jedenfalls eine Menge. Aber das muss
man individuell feststellen+lösen.

Ansonsten könnte man, wenn's nicht Zeit=Geld kosten würden, auch ne Menge Spaß
daran haben. Wenn nàmlich der Code auf 1/3 schrumpft weil diverse "Collection"-
Klassen oder API-Aufrufe wegfallen, oder man mit echten Konstruktoren arbeiten
kann, oder weil einen der VB.Net-Compiler auf diversen Müll hinweist, der so
auch in VB6 nie funktioniert hàtte, oder, oder... Hach, ist das schön...

Armin

Ähnliche fragen