Migration von klassischen Visual-Basic-Programmen nach .net (c# oder vb.net) oder Java

Sie wollen Ihr bestehendes Visual-Basic-Programm migrieren auf .net?

Nun nachdem die klassische Entwickleroberfläche von Visual-Basic abgekündigt worden ist, kristallisieren sich für spätere Updates die Oberflächen .net (geschrieben in C# oder VB.net oder Java SWT heraus. Natürlich gibt es mehr oder weniger automatische Konvertierungen der einen Software in die andere, doch wenn man die neuen technologischen Möglichkeiten der beiden Frameworks nutzen will, dann sollten Sie sich einmal den Beitrag Konvertieren von ehemaligen Visual-Basic-Projekten nach VB.NET vorher durchlesen. Hier ist klar gezeigt, dass eben nicht einfaches konvertieren das Gebot der Stunde ist, sondern ein Redesign.

Gut geplant dürfte bei gleicher funktioneller Leistung der Umstellungsaufwand bei 40-80% des Aufwandes liegen, der für die Erstellung der Software gebraucht wurde. Beim “Standard-VB-Code” kann man an vielen Stellen auf Programme zurückgreifen, die automatisch den Code von Visual-Basic nach .net konvertieren. Das kann, muss aber nicht in jedem Fall funktionieren.

Das Beispiel zeigt weiter: Sauber geplant haben Sie hinterher nicht gleiche funktionelle Leistung. Hätten Sie in Ihrem Programm die Funktion einer Stoppuhr, dann hätten Sie in jedem Falle nach dem Rewrite mehr. Die Funktion wäre in der Wartung unproblematischer und mit entsprechender Hardwareerweiterung oder Ergänzung auch von der Genauigkeit und der Zeitauflösung zu toppen. Und kein bisheriges Tool berücksichtigt die Windows-APIs. Hier sind manuelle Eingriffe gefordert.

Ob Sie diese innere Leistung also eine besser parametrierbare Stoppuhr dann in Ihrer Software verfügbar machen – also neben einem Konvertieren der Software diese auch noch erweitern und ergänzen, das bliebt Ihnen überlassen.

Wenn sie diesen Weg des Redesign und Rewrites gehen wollen, dann brauchen Sie weniger die konventionellen Konvertierprogramme, sondern mehr eine Person, die das Projekt zügig mit den Konvertern durchführt oder bei entsprechender Projektgröße ein entsprechendes Team.

Zu den Projektgrößen und ggf. zu den Möglichkeiten einzusparen

Als Mitglied der Consultpool ist die Zusammenstellung eines Entwicklerteams kein Problem inklusive eines Outsourcings von Programmteilen nach Rumänien oder Bulgarien. Dabei sollten Sie beachten, dass wir hier über Firmenangebote sprechen. Sie können natürlich auch selbst bei Seiten wie Active VB nachfragen und vielleicht übernimmt ein Schüler oder Student diese Aufgabe. Hier sollten Sie sich erfahrungsgemäß auf die Semesterferien beschränken, dann aber dürften Ihre Chancen nicht schlecht sein. Dabei sind erfahrungsgemäß die Projekte mit weniger als 1 Mannmonat einfacher und schneller zu realisieren – eben bezogen auf die Semesterferien. Natürlich würde ich auch ein 1 Mannmonatsprojekt abwickeln, allerdings nicht zu einem konkurrenzfähigen Preis im Vergleich mit einem Studenten.

Outsourcing in den Osten hat eine eigene Gesetzmäßigkeit. Sie müssen eine komplette Auftragsvergabe und Warenannahme inklusive Abnahmetests implementieren und so lohnt dies erst bei einer Projektgröße von mehr als einem Mannjahr.

Neben Outsourcing gibt es noch den Einsatz bestimmter Tools, die bei bestimmer Software sinnvoll sein kann, aber nicht sinnvoll sein muss. Sie haben den Preis des Tools, eine Vorbereitungszeit und als Ergebnis einen automatisch erzeugten Code, der zwangsläufig nur die Funktion des Altprogrammes anders darstellen kann.

Wohin wollen sie konvertieren, Java oder .net?

Damit – denke ich – sind die Projektgrößen klassifiziert und nun sollten Sie noch wissen, dass in der weiteren Zukunft neben dem Windows .net auch das Java einen Platz haben wird. Sie können vom VB-Programm aus konvertieren nach .net und dann werden Sie wie im gezeigten Beispiel an allen Soft- und Hardwareupdates des .net-Frameworks partizipieren.

Sie können aber auch nach Java konvertieren und haben dann ein Programm, dass auf jedem Rechner und jeder Plattform läuft. Dazu gehören die Linux-Varianten, die Mac-Betriebsysteme und auch die Windows-Plattformen und einige andere mehr.

Grundsätzliche Regel ist:

.net geht technologisch in die Tiefe und bietet interessante Detaillösungen, die Java-swt nur bieten kann, wenn diese allgemein verfügbar sind.
swt geht technologisch in die Breite und biete eine System-API nur an, wenn es diese auf allen Rechnern gibt.

Es gibt nichts auf der Welt, dass Sie daran hindern kann und sollte, beides zu verwenden. Brauchen sie irgendwo die technologische Tiefe, dann stellen Sie diese in einem Windows-Dienst zum Beispiel zur Verfügung. Das wird m.E. weniger die Uhr sein sondern mehr die verschiedenen Auswerte- oder Druckvorbereitungspakete. Diese Software ist geschrieben worden in .net für einen .net-Rechner. Braucht man diesen Dienst lokal, dann stellt man ihn auf dem Desktop zur Verfügung, braucht man ihn im Intranet, dann steht er auf einem Server bereit. Die Clients sind dann in Java-SWT geschrieben.

Mit diesem recht einfach gestrickten Beispiel sollte schnell klar sein, dass eine gute Konvertierung eines ehemaligen Visual-Basic-Programms nicht trivial ist und sauber geplant sein sollte.

Wie sieht es aus mit einer VBA-Konvertierung nach .net?

Unter VBA-Konvertierung verstehe ich zweierlei. Zum einen können Sie meinen, dass Sie ein altes Excel- oder Word-Makro modernisieren wollen, zum anderen kann es aber auch sein, dass Sie ein älteres Visualbasic-Programm haben, dass selbst eine eigene VBA-Runtime besitzt. Solche Programme habe ich einige geschrieben und damit werden auch die eigenen Programme “automatisiserbar”.

Der aktuelle Stand von Wikipedia lautet

Seitens des Herstellers Microsoft bestehen Überlegungen, VBA langfristig durch eine .NET-basierte Technologie zu ersetzen.

Dazu: Von Entwicklerseite man kann entweder eine solche VBA-Runtime integrieren, die VBA-Code verarbeitet (Es kann auch auf Java umgeschaltet werden) oder die .net-Code verarbeitet. Für den einen Fall muss man ein Automatisierungsobjekt erstellen, die eine COM-Schnittstelle anbietet und für den anderen Fall braucht man eine .net-Schnittstelle. Beides anzubieten ist m.E. bislang nicht möglich.

Dessen ungeachtet bleibt die Frage bestehen, in welchem Umfang sich der VBA-Code ändert, wenn man von einer klassischen VBA-Code-Struktur nach einer – ich nenne sie mal VBA.NET-Struktur wechselt. Die Codezeile

Sheets("Tabelle3").Select

dürfte m.E. sowohl in einem VBA-Script als auch in einem VBA.NET-Script die Tabelle mit dem Namen “Tabelle3” auswählen. Von der Syntax her sind nur geringe Unterschiede zu berücksichtigen, wenn man von VBA.NET nach C#A.NET wechseln würde, wenn also das Automatisierungsobjekt selbst auch in C# zu erstellen ist.

Falls Sie ein Programm zu konvertieren haben, sprechen Sie mich ruhig an.