Beste Strategie für den Wechsel von VB6 nach .NET [geschlossen]

Dies ist natürlich ein großes Unterfangen, das viel Arbeit erfordert Also wäre es ratsam, es wie ein sehr langfristiges Projekt zu behandeln.

Sie haben ein klares Ziel vor Augen, das wichtige Aspekte wie Sicherheit, Ausfallsicherheit, Wartbarkeit und die Zukunft Ihrer Anwendungen anspricht.

Sobald dies von den Stakeholdern vereinbart wurde, entwickeln Sie ein Prototypsystem, um Ihre Annahmen zu testen, wo Sie C # vrs VB.net oder MVC vrs Webforms ausprobieren können. Ich würde Ihre besten Entwickler dafür zuweisen.

Beginnen Sie dann mit einem Ihrer kleinen Legacy-Systeme und bauen Sie die Kernkomponenten auf, die Sie in anderen Bereichen wiederverwenden werden.
Beginnen Sie zu diesem Zeitpunkt mit Ihren älteren Entwicklern, aber jeder muss sich einbringen und mit dem neuen Framework vertraut sein.
Dadurch wird sichergestellt, dass alle gleichzeitig trainiert werden und niemand zurückgelassen wird.
Abhängig davon, wie viele Anwendungen Sie haben, würde ich Entwickler rotieren, so dass alle Systeme davon profitieren können.

Auch alle neuen Arbeiten müssen in Ihrer .net-Sprache erfolgen, nicht in VB6.

Konvertieren Sie schrittweise jede Ihrer älteren Anwendungen. (Ich würde sie nur konvertieren, wenn sie sich ändern oder wenn es einen klaren Vorteil bietet, sie zu aktualisieren.)

Dies sollte Ihnen ein solides Framework für die weitere Verwendung geben, während sichergestellt wird, dass die Benutzerfunktionalität durch Ihre Migration nicht behindert wird.

Zum Beispiel:
Ich habe bei einer Firma gearbeitet, die ungefähr 40 VB-Anwendungen hatte.
Im Laufe der Zeit haben wir alle auf C # migriert und jetzt (5 Jahre später) haben wir etwa 150 c # -Anwendungen (alle in .net 2.).

Diese haben alle einen gemeinsamen Rahmen, so dass sie leicht zu pflegen und gegebenenfalls zu erweitern sind.

Ersetzen Sie die Kernfunktionalität durch COM-fähige .NET-Bibliotheken. "Erweitern Sie Ihre bestehenden VB6-Apps, indem Sie die Funktionalität Stück für Stück nach .NET verschieben."

Vorsicht vor kompletten Umschreibungen. Obwohl sie verlockend sind, "weil es ein sauberer Schnitt ist" - normalerweise liegt der Wahnsinn vorn! Lesen Sie "Arbeiten effektiv mit Legacy Code" von Michael Feathers als Vorbereitung. Obwohl das Buch nicht speziell auf "den Übergang von einer Sprache in die andere" eingeht, zeigt es doch viele reale Fallstricke, denen Sie begegnen werden.

Ich denke, dass alle Entwickler Zeitfenster definiert haben sollten, in denen sie die Migration von Legacy-Apps durchführen, die sie zuvor entwickelt haben. Da sie bereits Domänenwissen haben und den Problemraum kennen, sollten sie am produktivsten sein.

Hier ist eine Anpassung meiner Antwort zu einer ähnlichen Frage.

Das automatische Konvertieren großer Programme ist eine bessere Wahl als das Neuschreiben. Es ist ein üblicher Fall, mit dem Optimieren einer großen Software zu beginnen, frühzeitig gute Fortschritte zu machen, einige der bekannten Fehler in der alten Architektur zu beheben und dann in der Funktionalität steckenzubleiben, die Sie gerade für selbstverständlich halten Jahre. An diesem Punkt wird Ihr Management nervös und alles kann sehr unangenehm werden.

... und hier ist ein Blogbeitrag von einem Microsofty, dass stimmt mir zu :

  

Viele Unternehmen, mit denen ich in den frühen Tagen von .NET gearbeitet habe, haben zuerst das Neuschreiben untersucht, zum Teil getrieben von dem starken Wunsch, die zugrunde liegende Architektur und Code-Strukturen zu verbessern, während sie gleichzeitig auf .NET umgestiegen sind. Leider sind viele dieser Projekte in Schwierigkeiten geraten und einige wurden nie abgeschlossen. Das Problem, das sie zu lösen versuchten, war zu groß

Diese ausgezeichnete Microsoft Seite empfiehlt zwei Fremdanbieter-Migrationstools, die besser sind als die unterentwickelten integrierten VB .NET Upgrade-Assistent - Artinsoft und CodeArchitects VBMigration . Artinsoft hat den eingebauten VB.NET Upgrade Wizard geschrieben, dies ist ihre verbesserte Version. Und CodeArchitects wurde von Francesco Balena gegründet, der einige der klassische Bücher auf VB6 und VB.NET.

Die gleiche Microsoft-Seite sagt auch:

  

Das vollständige Neuschreiben in .NET ist viel kostspieliger und schwieriger zu machen [als Konvertieren] ... wir würden diesen Ansatz nur für eine kleine Anzahl von Situationen empfehlen.

EDIT: Sung sagt in den Kommentaren: "Ich bin kein großer Fan der automatischen Code-Generierung, weil es anfänglich schwieriger zu debuggen ist und vielleicht genauso lange dauern würde, bis man das Ganze neu geschrieben hat". Ich muss stark widersprechen. Im Allgemeinen bin ich auch kein Fan von Code-Generierung, aber in diesem Fall wird der resultierende Code identisch zu Ihrem ursprünglichen VB6 strukturiert und sollte fast vollständig funktionsfähig sein. Ich habe diese Tools selbst noch nicht selbst ausprobiert, aber von ihrem Kunden testimonials Dieses Versprechen ist erfüllt.

Und ich wiederhole den Microsoft-Rat gerade oben, basierend auf ihrer Erfahrung bei der Unterstützung vieler Migrationen - "eine vollständige Neufassung ist viel kostspieliger und schwieriger als die Konvertierung [meiner Betonung]" - ein flacher Widerspruch von die Annahme, dass es die gleiche Zeit dauern könnte. Wenn Sie die Struktur des VB6 verbessern möchten, ist die Migration und schrittweise Refactoring wahrscheinlich weitaus kostengünstiger als ein Neuschreiben.

Siehe hierzu:
Ссылка

Natürlich ist C # vs VB.Net nur ein Teil davon.

Zum Beispiel sollten Sie sich überlegen, ob Sie diese Möglichkeit nutzen möchten, um diese Apps in ein Intranet zu verschieben, falls Sie dies nicht bereits getan haben. Oder wie tief möchten Sie in Microsofts Stack eintauchen? Ist Winforms ausreichend oder möchten Sie beispielsweise WPF verwenden?

Ich würde mit den Tools von Microsoft beginnen:

Ссылка

Sie könnten den folgenden Artikel nützlich finden: Ссылка