Wirbel um Visual Studio 2010: neues Modell für die Plug-in-Entwicklung

Inhaltsverzeichnis

Hinkte Visual Studio lange Zeit bei der Entwicklung von Plug-ins der freien Java-Entwicklungsumgebung Eclipse hinterher, versucht Microsoft mit der Einführung des Managed Extensibility Framework (MEF) in .NET 4 aufzuholen.

Schon lange darf Microsofts Entwicklungsumgebung Visual Studio als eine der umfangreichsten IDEs gelten. Dennoch ist nach all den Jahren die freie Entwicklungsumgebung Eclipse weiterhin um einiges mächtiger. Das liegt daran, dass für viele Entwicklungsszenarien hervorragende Plug-ins zur Verfügung stehen. Visual Studio hat in dem Kontext vergleichsweise wenig zu bieten. Die Ursache dafür liegt in dem viel zu komplex und unübersichtlich gestalteten Objektmodell der .NET-Schnittstellen für Entwickler. Eclipse bietet hingegen eine frei verfügbare Schnittstelle, die sich über XML ansprechen lässt, und insbesondere seitdem die modulare OSGi-Architektur die Basis für die Java-IDE ist, steht der Plug-in-Entwicklung unter Eclipse nichts mehr im Weg, frei nach dem Motto: "everything is a plug-in".

Das zentrale Interface zur Erweiterung von Visual Studio basierte bislang allein auf COM. Über der COM-Ebene liegen .NET Assemblies, die mit der COM-Schnittstelle agieren. Letztere bezeichnet man auch als Wrapper-Schnittstelle. Wrapper haben aber beiläufig einen Nachteil: Es lassen sich immer nur eingeschränkte Funktionen zur Verfügung stellen. Somit mag eine speziell gewünschte Funktion fehlen. Zudem sorgt, wie bei jeder COM-Technik, die enorm hohe Komplexität nicht gerade für ein Verständnis der dahinter liegenden Arbeitsweise.

Neues Plug-in-Konzept

Das neue .NET 4.0 enthält daher als neue Komponente das Managed Extensibility Famework (kurz MEF). Es fungiert zur Programmlaufzeit als leichtgewichtige Erweiterungsmöglichkeit der gewünschten Code-Logik. Bisher entwickelten .NET-Entwickler ihre Anwendungen erweiterbar und dynamisch, indem sie sie mühselig mit einer Plug-in-Infrastruktur versehen mussten. Große Teile der Infrastruktur hatten die Aufgabe, sich um das dynamische Laden von DLL-Assemblies und Typen zu kümmern.

Mit MEF lassen sich Anwendungen um Funktionen erweitern, die sich in externen Komponenten (DLL-Assemblies) befinden. Diese können wiederum andere externe Komponenten verwenden. Es reicht lediglich aus, ein Interface zur Verfügung zu stellen, das das Attribut "Export" enthält. Für die spätere Auflösung der Abhängigkeiten sorgt das Framework. Es erkennt zur Laufzeit die Assemblies, die das Interface und "Export" implementiert haben. MEF ruft ähnlich wie bei einem Service Locator oder bei Dependency Injection die gefundenen Assemblies auf und stellt deren Instanz bereit. Anwendungsentwickler müssen sich also nur noch um die Implementierung der Funktionen kümmern, die das Interface vorschreibt. Die neue MEF-Technik gibt somit dem Entwickler den Weg zur gewünschten Funktion vor, während bisher immer komplexe Objektaufrufe und Events bekannt sein mussten.

Erweiterbarkeit in VS 2010

Die neue Erweiterbarkeit

Obwohl große und wichtige Bestandteile von Visual Studio 2010 weiterhin auf COM basieren, sind nun viele wichtige Komponenten auf .NET-Ebene integriert. So ist die Basis des Sourcecode-Editors jetzt die Windows Presentation Foundation (kurz WPF), die seit .NET 3.0 als neue UI-Technik fungiert. Das bedeutet auch, dass Microsoft bei der Schnittstelle das alte Wrapper-Modell um MEF erweitert hat. Das verschafft dem Entwickler eine vereinfachte und erweiterte Entwicklungsoption. Programmierer müssen aber viele Funktionen auch weiterhin mit COM ansprechen, denn nur neuere Teile der IDE sind über MEF und .NET erweiterbar, alte Bestandteile benutzen die COM-Schnittstellen oder Visual Studio Automation (EnvDTE). Allein für Visual-Studio-Projekte gibt es mindestens drei Klassen [IVsProject (COM), Project (EnvDTE), Project (MSBuild)]. Für den Einsteiger ist es schwierig zu erkennen, über welchen Weg er eine bestimmte Funktion am besten implementieren kann, zumal es für einige Teile alte (COM) und neue (MEF) Schnittstellen gibt und viele Tutorials noch die alten Schnittstellen erklären, obwohl die ersten Projekte die verbesserte Integration bereits verdeutlichen.

Zur Veranschaulichung sei ein besonderes Augenmerk auf eine Diplomarbeit geworfen, die eine Verwaltung zur Internationalisierung von WPF-Anwendungen bietet. Die ersten Bilder dazu zeigen, wie eine perfekte Integration die Arbeit des Entwicklers unterstützt. Er kann sich auf seine Standard-Elemente konzentrieren und wie gewohnt weiterarbeiten.

Denn WPF-Anwendungen lassen sich nicht mehr so einfach und bequem im Designer in andere Sprachen übersetzen, wie es noch bei Windows-Forms- oder ASP.NET-Anwendungen möglich war. Weder Visual Studio 2010 noch Expression Blend 4 bieten eine direkte Unterstützung für die Lokalisierung von WPF-Anwendungen. Es gibt zwar eine Lokalisierungs-API für WPF, doch für sie findet man lediglich eine für die Praxis ungeeignete Beispielanwendung. Alternativ dazu sind in der Community unterschiedliche Ansätze zu finden, um WPF-Anwendungen zu lokalisieren, die jedoch ihrerseits unterschiedliche Nachteile mitbringen.

Aus dem Grund entwickelt Mathias Raacke im Rahmen seiner Diplomarbeit zurzeit ein Plug-in für Visual Studio 2010, das die Lokalisierung von WPF-Anwendungen erheblich vereinfachen soll und auch den Übersetzer in die Lokalisierung mit einbindet. Denn im Gegensatz zu bisherigen professionellen Lokalisierungswerkzeugen ist sein Plug-in NLocalize direkt in Visual Studio integriert. Das vereinfacht die Konfiguration der Lokalisierung, und der Entwickler kann seine Anwendung in seiner gewohnten Entwicklungsumgebung übersetzen.

Für Übersetzer gibt es eine eigene Software, die einfach zu bedienen ist. Beide Versionen bieten eine visuelle Vorschau der übersetzten Benutzeroberfläche. Der Datenaustausch zwischen Entwickler und Übersetzer erfolgt über einen Server, der zum Beispiel unter Windows Azure laufen kann. Das spart Zeit, da die übersetzten Ressourcen nicht umständlich per Mail zu verschicken sind, sondern sich bequem per Knopfdruck austauschen lassen.

Fazit

Durch die neue Flexibilität ist Visual Studio 2010 bei weitem mächtiger als seine Vorläufer. Es wird spannend sein zu beobachten, welche Tools einen großen Einfluss auf die Entwicklungsgewohnheiten nehmen werden. Denn der Funktionsumfang ist so groß wie nie und bietet Highlights wie Architektur- und Sequenzdiagramme, F#, Unterstützung für Test-Driven Development (TDD) oder das Debugging mit IntelliTrace. Microsoft will ein besonderes Versprechen einlösen: ALM (Application Lifecycle Management) für jeden. Somit ist ein allgemeiner Eindruck der neuen IDE viel versprechend. Bis auf ein paar Performance-Aspekte wird die neue Version mit großer Sicherheit auf Beliebtheit stoßen.

Gregor Biswanger
ist Solution Architect und Silverlight-Fachexperte bei der Firma impuls Informationsmanagement GmbH in Nürnberg. Seine Schwerpunkte liegen im Bereich der .NET-Architektur und agiler Prozesse. Sie erreichen ihn über seinen Blog.
.
(ane)