VB6 COM+ Migration - Architekturvorschläge

Hallo zusammen,

wir haben in unserem Unternehmen ein System das in VB6 geschrieben ist und COM+ Komponenten nutzt die ebenfalls in VB6 geschrieben sind. Dazu gibt es einmal das Hauptprogramm und unzählige weitere Tools in VB6, VB.NET und C# geschrieben. Darunter sind ua .NET Webservices sowie ACCESS Tools, Excel Plugins etc pp.

Nun hat man entschlossen dieses System nach .NET zu migrieren.

Da es praktisch neu geschrieben wird, tendieren wir dazu dieses System mit WCF/WPF aufzusetzen.

Da der Aufwand für die Anpassung aller "alten" Tools, Excel Addins und und und schnell in die Monate gehen könnte soll das doch gut überlegt werden. Abgesehen davon weiss ich nicht ein mal ob ein Excel Plugin überhaupt in der Lager wäre einen WCF Service zu konsumieren.

Ich könnte da grad noch soviel zu schreiben aber ich denke mein Grundproblem ist erkennbar oder?

Eventuell hat ja irgendwer schon Erfahrungen damit gemacht. Ich wäre sehr sehr froh wenn jemand von euch mit mir über die Architektur diskutieren würde 😃

Gruss
Marcel

Es ist eigentlich vollkommen ausgeschlossen, das wir dir hier im Forum helfen können.

1. Das bisschen Info reicht bei weitem nicht aus etwas dazu zu sagen.
2. Braucht schon ein echter Architekt für die konkrete Ausarbeitung solch eines Projektes vor Ort mit den entsprechenden "Kunden" sicherlich mehr als eine Woche.
   Und das wäre dann Vollzeit.

Und ihr solltet das nicht als ein Migrationsprojekt ansehen, dann werdet ihr scheitern.
Es ist besser es als ein neues Projekt anzusehen, das "nur" alle Features des bisherigen haben soll, sonst verbaut ihr euch da viele Sachen.

Ja das ist so pauschal ausser mit den üblichen Ratschlägen kaum zu beantworten.
Machs top-down. Die Lieferanten Server etc. zuerst. Dann die Clients dann die Tools. Halt dich nicht zu starr an dem Migrationsgedanken fest. Ihr erstellt ein neues System. Mach den beteiligten klar das einiges in Zukunft dadurch zwangsweise anders muss. Aber wie schon gesagt, das ist nich mehr als das übliche.

Und ihr solltet das nicht als ein Migrationsprojekt ansehen, dann werdet ihr scheitern.

Diese Aussage halte ich für zu pauschal. Das klingt nach "Schauen wir mal in die Kristallkugel". Natürlich ist es utopitsch zu glauben, man importiert den VB6-Code mit dem Migrations-Assistenten von Visual Studio und fertig ist das neue .NET Projekt. Den Eindruck hatte ich aber von marcelws aber definitiv nicht.

Da es praktisch neu geschrieben wird, tendieren wir dazu dieses System mit WCF/WPF aufzusetzen.

WCF liegt auf der Hand. WPF würde ich mir derzeit noch gut überlegen. Man erreicht bei WPF nicht mal annähernd die Produktivität wie bei Windows.Forms. Der Visual Studio-Designer ist grauenhaft bis unbrauchbar und Expression Blend ist eher was für Künstler, als für Entwickler. Hinzu kommt, dass es besonders für die alten VB6-Hasen ein krasser Schnitt ist. Windows.Forms funktioniert fast genauso wie die Forms in VB6, aber WPF ist komplett anders. Darüber solltest Du nachdenken. Das Neuste muss nicht immer das Beste sein!

Abgesehen davon weiss ich nicht ein mal ob ein Excel Plugin überhaupt in der Lager wäre einen WCF Service zu konsumieren.

ja kann es! Sogar VBA kann das. Du musst nur das SOAP Toolkit bzw. die Redistribution davon auf den Clients installieren: Download Microsoft SOAP Toolkit 3.0

Eventuell hat ja irgendwer schon Erfahrungen damit gemacht. Ich wäre sehr sehr froh wenn jemand von euch mit mir über die Architektur diskutieren würde 😃

Ich habe Erfahrung in der Migration von VB6 und Access auf .NET. Auch in Sachen verteilte Anwendungen und Enterprise Services (COM+). Wenn Du die aktuelle Architektur etwas näher beschreibst, können wir gerne darüber diskutieren.

Ihr wollt das ganze komplett neu schreiben? Es gibt auch die Möglichkeit einer fließenden Migration. Dabei wird die Applikation modulweise, also Stück für Stück migriert. Das erfordert etwas zusätzlichen Aufwand, für Interop-Glue-Code, aber die Anwendung muss dafür nicht zweigleisig supported werden. Für VB6 gibt es sehr gute Unterstützung, um .NET Assemblies in der "Alten Welt" aufzurufen. Da sei allen voran z.B. das Interop Forms Toolkit genannt. Vielleicht ist fließende Migration ja auch ein Thema.

Diese Aussage halte ich für zu pauschal.

Nein.
Denn dann bleiben sie bei der Architektur von einem VB6 COM Projekt und diese Architektur mag sich ja in den letzten 12 Jahren bewährt haben, ist aber bei den neuen Möglichkeiten und Wegen suboptimal und mit .NET mitteln dann auch nur durch viel Frickelarbeit zu lösen ( z.b. Interop Toolkit ).

Ich finde es eher bedenklich langsam zu migrieren, dann schleppt man nämlich den ganzen VB6 Müll mit und da habe ich persönlich in den letzte 10 Jahren Sachen gesehen.....

Denn dann bleiben sie bei der Architektur von einem VB6 COM Projekt ...

Das muss nicht sein. Wenn die alten VB6-Module nur über eine eingezogene Integrationsschicht auf die neuen .NET Assemblies zugreifen (und umgekehrt), lässt sich das trennen. Es ist aber - wie gesagt - etwas mehr Arbeit.

und diese Architektur mag sich ja in den letzten 12 Jahren bewährt haben, ist aber bei den neuen Möglichkeiten und Wegen suboptimal und mit .NET mitteln dann auch nur durch viel Frickelarbeit zu lösen ( z.b. Interop Toolkit ).

Wenn sich das "Frickeln" auf die Integrationsschicht beschränkt oder auf VB6-Seite bleibt ist das okay, da die VB6-Module dann ja nach und nach entsorgt werden. Nur in den neuen .NET-Modulen (außer der Integrationsschicht) muss alles sauber bleiben. Dort darf z.B. niemals ein COM-Objekt instanziiert werden. Wenn, dann wird es in einen .NET-Wrapper verpackt und von der Integrationsschicht injeziert.

Ich finde es eher bedenklich langsam zu migrieren, dann schleppt man nämlich den ganzen VB6 Müll mit ...

Natürlich dauert es länger. Dafür benötigt es wesentlich weniger Ressourcen. Niemand muss parallel das alte System pflegen, bis das neue komplett fertig ist (was u.U, Jahre dauern kann, wenn es komplett neu geschrieben werden muss). Die Kunden werden u.U. auch Stück-für-Stück auf die neue Technologie gehoben.
Wenn z.B. ein kleines Team eine große Anwendung über Jahre entwickelt hat, ist die komplette Neuentwicklung u.U. gar nicht zu stemmen.

... und da habe ich persönlich in den letzte 10 Jahren Sachen gesehen.....

Das kann ich mir vorstellen. Ich verstehe auch, dass Du deshalb "vorbelastet" bist, was Migrationsprojekte angeht. Meistens kommen solche Projekte zum Kollaps, wenn die Entwickler in der neuen Technologie nicht wirklich sattelfest sind und/oder alte und neue Welt direkt miteinander zu einem riesigen Klumpatsch verwoben werden.

Aber es muss nicht zwangsweise so sein! Es geht auch anders.

Aber was meinst Du wieviele Entwickler, die jetzt von VB6 umsteigen sind so Sattelfest das das Sinn macht?

Bestimmt sind es starke 50% nicht. Genau kann ich das nicht sagen. Kommt auf das jeweilige Team an. Ich habe schon Projekte gesehen, bei welchen die Entwickler so sattelfest waren.