Projekt mit VB und C#

Question

Hallo NG,

ich habe ein VB Projekt mit vielen Windowsform-Elementen. Die zum Teil sehr alten Elemente möchte ich nicht mehr bearbeiten. Moderne und funktionale UI-Oberflächen lassen sich scheinbar gut mit WPF und Xaml programmieren.

In diesem Zusammenhang habe ich zwei Fragen:

1. Kann ich in einem Projekt sowohl die bestehenden Windowsformkomponenten als auch neue Element mit Xaml programmieren?
2. Scheinbar ist die Programmiersprache C#, weiter verbreitet als VB, insbesondere sind die meisten Beispiele für WPF und Xaml in C# geschrieben, sodass es für mich sinnvoll sein könnte, neue Sachen in C# zu programmieren. Kann man in einem Projekt Teile in VB und anderer Teile in C# programmieren. Nach meiner Suche im Internet scheint man das wohl nicht zu können.

Mit freundlichen Grüßen

Dipl. Ing.  Joachim Schmäck

---

Mit freundlichen Grüßen Dipl. Ing. Joachim Schmäck

Answer 1

Hi Joachim,
die erste Frage ist eindeutig mit ja zu beantworten. Es gibt da zwei Wege. Unterschiedliche Teilprozesse können nebeneinander existieren, z.B. wird aus einem XAML-Windows ein Windows Form zur Anzeige gebracht und umgekehrt. Ein anderer Weg ist die Nutzung des Hostings eines Windows Forms in einem XAML (WindowsFormsHost) oder umgekehrt ein XAML-Windows in einem Windows Form (ElementHost). Ich würde aber den Weg mit UserControls gehen, die in WPF erstellt werden and dann in Windows Forms oder auch in WPF Oberflächen eingesetzt werden können.

Der 2. Punkt ist Gewöhnungssache. Ich bevorzuge VB, da die "blumenreichen Sprachelemente" einem weniger gewohnten Programmierer einen schnelleren Überblick verschaffen gegenüber den nichtssagenden vielen Klammern in C#. Wer jedoch bisher in C oder Java programmiert hat, dem wird C# besser gefallen. Der Funktionsumfang von VB.NET und C#.NET ist identisch. Die einzige störende Abweichung ist mir bisher als Sonderfall der Objekt-Initialisierung untergekommen, der in VB.NET nicht mit einer Anweisung wie in C#.NET möglich ist, so dass eine Workflow-Aktivität in VB.NET nicht möglich ist, da dort eine Objektinitialisierung in nur einer Anweisung gefordert wurde.

Problematisch kann VB.NET werden, wenn man langfristig ASP.NET Core Anwendungen erstellen will. Da gibt es z.Z. noch keine Projekt-Vorlage für VB.NET (soll aber angeblich noch kommen).

Wer sich in VB wohlfühlt und damit effektiv umgehen kann, sollte auch dabei bleiben. Wichtig ist jedoch, dass man sich auch mit der Sprachsyntax von C#.NET beschäftigt, um diesbezügliche Beispiele zu verstehen.

Wichtig ist auch: In einem Projekt müssen alle Programme in der gleichen Programmiersprache sein. VB.NET-Windows Forms in VB.NET WPF können sich in einem Projekt befinden. Ich würde das aber nur als Sonderfall nutzen.

Viel wichtiger ist beim Umstieg das zu nutzende Entwurfsmuster. Und da würde ich sofort die WPF Programmteile in MVVM entwerfen.

Wenn die alte Anwendung gut in Schichten strukturiert war, dann würde ich zu Beginn nur die Oberfläche neu gestalten bei Beibehaltung der Datenzugriffsschicht und der Geschäftsschicht. Zwischen alter Geschäftsschicht und neuer WPF Oberfläche würde ich eine zusätzliche neue Geschäftsschicht legen, die dann optimal MVVM realisiert und später schrittweise die alte Geschäftsschicht ersetzen kann und ggf. eine modernere Datenzugriffschicht nutzt

---

--
Viele Grüsse
Peter Fleischer (ehem. MVP)
Meine Homepage mit Tipps und Tricks

Answer 2

Hallo Peter,

danke für deine schnelle und ausführliche Antwort. Ich bin Hobbyprogrammierer, ich habe mit Sinclair und C64 angefangen, da war Basic noch Basic! Meine Programme laufen und sind nützlich aber ganz bestimmt nicht „gut in Schichten strukturiert“.

Ich habe deinen Vorschlag gestern mal probiert, der Weg über UserControls sieht für mich gut aus und so werde ich erst einmal versuchen mich dem Thema WPF und Xaml zu nähern.

MVVM sieht interessant aus, könnte aber für mich jetzt einen Schritt zu weit sein.

In einer Projektmappe kann man Projekte in verschiedenen Sprachen zusammenfügen, zu Übungszwecken kann ich also auch mal ein Projekt in C# einbauen, dann kommt natürlich die Frage auf, wie man den vom Compiler erzeugten Code später zusammenbringt, wenn es sich nicht um DLLs handelt. Wahrscheinlich muss man die verschiedenen EXE einfach ansprechen.

---

Mit freundlichen Grüßen Dipl. Ing. Joachim Schmäck

Answer 3

Hi Joachim,
jedes Projekt in einer Projektmappe kann nur in einer Programmiersprache entwickelt werden. Das Zusammenfügen geht über Verweise (References). Eine exe wird als Übersetzungsergebnis eines Projektes erzeugt. Damit die weiteren Projekte von der exe genutzt werden können, werden sie als Klassenbibliotheken (dll) aufgebaut. Zugegriffen wird auf die Innereien in den Klassenbibliotheken über Verweise und Imports (bei VB.NRT) in den Code-Dateien. Die verschiedenen dll's können in jeweils eigener Programmiersprache erstellt werden. Dank der einheitlich MSIL (Zwischencode, den der Compiler erzeugt), passen sie problemlos zusammen.

Mit MVVM lohnt es sich zu beschäftigen, auch, wenn es am Anfang den Lernaufwand etwas vergrößert. Der wesentliche Vorteil liegt in der damit erreichbaren Übersichtlichkeit des Projektes. Durch die Trennung von Programmlogik und Oberflächengestaltung in MVVM führen Änderungen der in der Gestaltung der Oberfläche praktisch zu keinen Problemen in der Programmlogik, außer natürlich, wenn in der Programmlogik etwas vergessen wurde, was dann in der Oberfläche benötigt wird.

Die Idee mit den UserControl kann aber zu Problemen führen, wenn die UserControls in der gleichen Assembly (Projekt) enthalten sind. Sie sollten immer in separaten Assemblies (dll / Projekte) enthalten sein. Wenn z.B. ein UserControl auf einer Form oder Window platziert wird, dann kann bei Änderungen des UserControls die Designer-Oberfläche den Dienst versagen (ggf. bis zum Absturz des Visual Studios). Wenn die UserControls dagegen in einer separaten dll (Asselbly / Projekt) enthalten sind, dann passiert nichts, solange sich die Version nicht ändert (* in der Assembly-Versions-Information). Da das Visual Studio ein umfangreiches Caching nutzt, kann es vorkommen, dass Änderungen im Projekt mit den UserControls nicht sofort auch im Designer der Fenster dem exe-Projekt erscheinen. Wenn jedoch mit automatischer Versionierung (mit * in der Assembly Information) gearbeitet wird, kann es passieren, dass der Designer im exe-Projekt seinen Dienst versagt, wenn im UserControl-Projekt etwas geändert wurde und deshalb die alte dll-Version nicht mehr zur Verfügung steht.

Das alles sollte beachtet werden und die UserControls zuerst möglichst umfangreich ausgetestet werden, damit es so wenig wie möglich spätere Änderungen ergeben. Um die Probleme des Designers zu umgehen, kann man für umfangreiche Tests der UserControls diese nicht mit dem Designer platzieren, sondern im Hintergrund-Code des Fensters, z.B. im Load-Ereignis. Das ermöglicht auch ein problemloses Debuggen. Wenn das UserControl mit dem Designer platziert wird und man debuggen will, muss man das über eine zweite Instanz des Visual Studios machen, was etwas aufwändiger ist.

---

--
Viele Grüsse
Peter Fleischer (ehem. MVP)
Meine Homepage mit Tipps und Tricks