Im nächsten Jahr wird sie kommen, die 2005er Ausgabe von Visual Studio. Zeitgleich gibt es neue .NET-Versionen von Visual Basic, C# und C++ sowie der Common Language Runtime (CLR) und der Base Class Library (BCL). Die erste Beta für Visual Studio 2005 ist seit kurzem zu haben - und alle Neuheiten bei .NET fließen in Microsofts kommender Entwicklungsumgebung natürlich zusammen. Ein guter Zeitpunkt, um einen Blick auf die erste Beta von Visual Studio zu werfen.
Einen Einblick in die wichtigsten neuen Features von .NET 2.0 gibt der tecChannel-Beitrag Die .NET CLR - Version 2.0. Aus diesem Grund widmet sich dieser Beitrag ausschließlich den Neuerungen in Visual Studio selbst und geht nicht auf Änderungen an den Sprachen oder der .NET CLR und BCL ein.
Das neue Visual Studio hat nicht nur eine neue an Office XP angelehnte Optik erhalten, sondern auch eine Vielzahl neuer Features und Verbesserungen an bereits bestehenden Features. Es gibt neue Editoren wie zum Beispiel den Klassen-Designer, neue Editor-Modi wie etwa die "Properties Mode View" des Windows-Forms-Editors, Verbesserungen beim Debugger in Form von "Debugger Visualizations" und eine allgemein verbesserte Produktivität durch Intellisense, Code Expansion und Refactoring für den Quellcode-Editor.
Dazu kommt eine Unzahl an weiteren Erweiterungen und Verbesserungen: Weit mehr, als in diesem Beitrag aufgeführt und erläutert werden können. Allerdings sind zwei Jahre Pause seit der letzten Version der IDE auch eine lange Zeit - und die ist deutlich spürbar.
Installation
Wer die aktuelle Beta von Visual Studio schon vorab testen will, kann das übrigens leicht tun: Dazu brauchen Sie lediglich ein (kostenpflichtiges) MSDN-Abo. Über die "Subscriber Downloads" von MSDN kann man die Beta dann herunterladen und selbst ausprobieren.
Im Vergleich zur Version 2003 hat sich bei der Installation des neuen Visual Studio nicht viel geändert: Zunächst ist die aktuelle .NET-Laufzeitumgebung in Version 2.0 zu installieren. Dann kann man Visual Basic, C#, C++, J# und den "Visual Web Developer" einrichten. Dazu kommen noch die "Enterprise Tools", das Framework-SDK und andere Toolsets.
Eine kleine Überraschung bietet sich aber beim Setup schon: Integriert ist nämlich auch der Device Emulator in Version 1.0. Mit Visual Studio 2005 kann man auch Anwendungen für Windows CE, Pocket PC 2003 und Smartphone OS 2003 entwickeln, das dazu benötigte .NET-Compact-Framework ist dabei. Wer kein "Smart Device" sein Eigen nennt, kann trotzdem für diese Geräte entwickeln und auf dem Device Emulator austesten.
Erster Start
Öffnet man ein erstes Testprojekt, bemerkt man schon die erste kleine - aber sehr angenehme - Verbesserung. Bei den bisherigen Versionen legte Visual Studio für jedes neue Projekt auch ein Projektverzeichnis mit Projektdateien und allem Drum und Dran an, auch für Testprojekte, mit denen man eventuell nur schnell eine Kleinigkeit ausprobieren will. Man kam dabei beim Testen schnell von "WindowsApplication1" über "WindowsApplication22" zu "WindowsApplication130". Diese Zeiten sind vorbei: Wer einfach nur ein Testprojekt anlegen will, schaltet die Option "Create Directory for Solution" aus. Dadurch bleibt es temporär und hinterlässt keine unangenehmen Spuren auf der Platte.
Bei großen Projekten oder mehreren Beteiligten kommt man ohne eine Versionsverwaltung nicht aus. Bei Visual Studio 2005 gibt es ab sofort nicht mehr eine, sondern gleich zwei unterschiedliche Revision Control Systeme: Die normale Version arbeitet wie gewohnt mit Visual Source Safe, das "Visual Studio Team System" ist dagegen ein separates Produkt, das sich aus verschiedenen Komponenten für die Software-Entwicklung in größeren Teams zusammensetzt und neben der Versionskontrolle auch Unit-Test-Tools und andere Werkzeuge enthält. Da das Team-System allerdings bei der Professional-Version von Visual Studio nicht beigepackt sein wird, geht dieser Beitrag auch nicht weiter auf Team-System ein.
Neue Funktionen der BCL
Wer mit Windows-Forms arbeitet, erhält von Visual Studio natürlich Unterstützung für die neuen Objekte aus dem Windows-Forms-Namespace und den anderen Teilen der BCL. Das macht sich als erstes in der Toolbox bemerkbar, die mit einer ganzen Reihe neuer Controls aufwarten kann. Diese gibt es wie gewohnt in zwei Geschmacksrichtungen: die eine für Windows-Forms, die andere für ASP.Net.
Die Fensterverwaltung in Visual Studio hat sich nicht grundlegend verändert: Man wählt weiterhin zwischen einer Anordnung als "MDI" oder als "Tabbed Documents" für die Dokumenten-Fenster aus. Allerdings muss man beim Umschalten zwischen den beiden Darstellungsformen Visual Studio nicht mehr neu starten, wie das bei den Vorgängerversionen der Fall war.
Gelungen: Das neue Docking
Das Andocken von Fenstern hat Microsoft deutlich besser gelöst als bisher. Sobald ein Fenster mit der Maus positioniert wird, öffnen sich so genannte Docking-Helper. In jedem andockbaren Bereich weist ein solches Hilfs-Control auf die Positionen hin, an die das Fenster gedockt werden kann. Man sucht also nicht länger nach der "richtigen" Position irgendwo am Fensterrand, sondern zieht die Maus einfach an die richtige Stelle im Hilfsobjekt, um die gewünschte Position zu erreichen.
Den Forms-Editor hat Microsoft gründlich überarbeitet. So sind viele Eigenschaften von Controls auf den Forms jetzt direkt editierbar, und auch die neuen "ToolStrip"-Controls für ToolBars, Menüleisten und die Statuszeile werden direkt unterstützt. So kann man beim neuen Studio nicht nur den Text für einen Menüpunkt, sondern auch das zugehörige Bitmap direkt im Editor festlegen.
Zusätzlich verfügt der Forms-Editor über ein menüartiges Control, mit dem sich Aktionen und Eigenschaften für die einzelnen Kontrollelemente einfacher festlegen lassen. Die Controls erhalten dazu am Bildschirm einen kleinen Pfeil, über den das "Actions"-Menü sich öffnen lässt.
Im Fall der ToolBars kann man damit beispielsweise die Dock-Position festlegen, der Name des Controls ist bei praktisch allen Kontrollelementen festlegbar.
Forms-Editor kennt neue Tricks
Zusätzlich hat Microsoft dem Forms-Editor einen neuen Betriebsmodus spendiert: Die so genannte "Property-Editing View". Dabei handelt es sich um eine Ansicht, in der die Namen der einzelnen Controls direkt im Forms-Editor angezeigt werden. Die Anzeige erfolgt dabei per Control in einem Tooltip. Klickt man in das Tooltip, so verändert sich dieses in ein Edit-Control, in dem man den Namen des Elements ganz nach Wunsch eingeben kann. Das ist deutlich effizienter als das einzelne Anklicken der Objekte auf dem Forms, um dann deren Namen mühselig im Property-Grid zu verändern. Die Property-Editing View aktiviert man über das Objektmenü des Forms. Hier kann man diese Ansicht auch wieder deaktivieren.
Und noch eine Neuheit gibt es beim Forms-Editor: Die Dokument-Übersicht (Outline). Wer schon einmal ein HTML-Dokument mit Visual Studio bearbeitet hat, kennt diese Ansichtsform. Sie zeigt den Inhalt des HTML-Dokuments in einer Baumstruktur, die alle Zusammenhänge zwischen über- und untergeordneten Elementen darstellt.
Genau diese Ansicht kann man nun auch für den Forms-Editor auswählen. Bei kleinen Dialogen macht die Ansicht nicht sonderlich viel Sinn, bei komplizierten Fenstern verhält sich die Sache dagegen anders, denn hier ist es oft nicht besonders einfach, bestimmte Controls anzuwählen. Mit der Dokument-Übersicht ist das nun extrem einfach: Ein Klick in dieser Ansicht wählt das Kontrollelement auch auf dem Dialog aus.
Weitere Neuigkeiten beim Forms-Editor
Und schließlich gibt es noch eine Hilfe für das Positionieren von Controls im Forms-Editor: Die einzelnen Kontrollelemente haben Abstandshalter, die die umliegenden Kontrollelemente automatisch berücksichtigen. Damit erspart man sich das bisher eher mühselige Justieren von Kontrollelementen. Wer viele Dialoge gestalten muss, wird allein schon wegen der Positionierungshilfe der fertigen Version von Visual Studio entgegenfiebern.
Keine besonderen Überraschungen bieten der Solution-Explorer und die Check-ins- Ansicht für VSS: Hier gibt es zwar einige neue Icons, aber nichts wesentlich Neues. Man muss allerdings von vornherein mit deutlich mehr Dateien pro Projekt leben als bisher. Visual Studio teilt eine Klasse in mehrere Dateien auf, um den automatisch erzeugten Code vom Code des Programmierers zu trennen.
Brandneu: Der Klassen-Designer
Mit dem neuen Klassen-Designer verleiht Microsoft dem Prefix "Visual" deutlich mehr Gewicht, denn er ermöglicht es, Typen tatsächlich visuell zu erstellen und zu bearbeiten.
Dazu gibt es eine spezielle Ansicht, die sich aus zwei Fensterteilen zusammensetzt. Das eine ist die "Class Diagram"-Ansicht, das andere die "Class Design"-Ansicht. Dabei handelt es sich jeweils um eine andere Darstellungsform des Quelltextes. Im Klassendiagramm werden die vorhandenen Typen als "Formen" dargestellt und innerhalb dieser die Felder, Eigenschaften und Methoden. Bei der Design-Ansicht handelt es sich einfach um eine tabellarische Ansicht der einzelnen Felder, Eigenschaften und Methoden des Typs.
Änderungen im Quelltext machen sich sofort im Klassendiagramm bemerkbar und umgekehrt: Das Klassendiagramm ist also nur eine andere Darstellungsform des Quellcodes, die sich dynamisch anpasst.
Um mit dem Klassen-Designer einen neuen Typ zu definieren, zieht man eine neue Form aus der Toolbox des Klassen-Designers auf die Design-Oberfläche: Visual Studio erzeugt die benötigten Dateien automatisch. Die "Form" (Shape) kann man per Mausklick um neue Felder oder Methoden erweitern.
Der Klassen-Designer bietet aber auch weiter gehende Features: So kann man damit zum Beispiel durchaus Vererbung unter zwei Typen darstellen. Dazu klickt man auf den "Inheritance" Button in der Class-Designer-Toolbox und zieht eine Linie von der spezialisierten Klasse auf ihre Basisklasse. Der Quellcode wird automatisch auf den neuen Stand gebracht.
Optisch sind die vom Designer erzeugten Diagramme durchaus ansprechend - ob der Designer allerdings wirklich ein probates Mittel zur Entwicklung neuer Klassen und Klassenbäume ist, hält zumindest der Autor für fraglich. Zum Verständnis fremden Codes, besonders bei größeren Projekten, wird der Designer aber bestimmt beitragen: Da das Klassendiagramm einfach nur eine Repräsentation des Quellcodes ist, kann man damit auch für bereits vorhandenen Code Diagramme anzeigen lassen und somit die Verknüpfungen besser verstehen.
Refactoring, Intellisense Code Expansion und Code Snippets
Auch wer eher seinen Code lieber selbst tippt, statt ihn per Maus zu designen, bekommt mit Visual Studio 2005 eine geballte Ladung Neuheiten, und zwar im Quellcode-Editor. Diese spielen dabei alle ein wenig ineinander und hören auf die Namen "Refactoring", "Intellisense Code Expansion" und "Code Snippets".
In allen Fällen geht es letztlich darum, dass die IDE eine ganze Menge über den momentan bearbeiteten Quellcode und das zugehörige Projekt oder die Projekte weiß, und darum zum Teil praktische Hilfestellungen anbieten kann.
Ein einfaches Beispiel dafür ist die Unterstützung für Generics in .NET 2.0, die sich auch auf Visual Studio und damit auf Intellisense ausgebreitet hat. Wenn Sie beispielsweise eine Instanz einer Klasse Liste<Person> instanziieren und dann die Methode Add() der Liste aufrufen, so schlägt Intellisense auch direkt nur Objekte vom Typ Person vor. Wählt man etwas anderes, so bemerkt die IDE dies sofort und bemängelt das mit den bekannten roten Schlangenlinien.
Mit der Code Expansion (mit Snippets) will man den Tippaufwand verringern, also eine Art Erweiterung von Intellisense, denn damit kann man ja auch schon den Tippaufwand minimieren.
Beim bisherigen Intellisense geht das so, dass beispielsweise nach der Eingabe von "new" der Editor automatisch eine Liste möglicher Objekte anbietet. Statt nun den Namen des Objekts vollständig einzugeben, reicht ein Druck auf die Leertaste (oder Tab), und der Klassenname wird automatisch eingefügt.
Die Code-Expansion geht dabei einen Schritt weiter. Hier gibt es eine (erweiterbare) Liste vorgefertigter Abkürzungen. Will man beispielsweise eine neue Klasse anlegen, so reicht die Eingabe von "class" und ein Druck auf "Tab". Die IDE erzeugt dann automatisch das komplette Klassengerippe und positioniert den Cursor innerhalb des vorgegebenen Namens der Klasse. Wenn man diesen überschreibt und danach Return drückt, landet man automatisch innerhalb der geschweiften Klammern. Das Manövrieren per Cursor-Tasten entfällt also.
Einfache Funktionalität - große Wirkung
Gleiches funktioniert mit anderen häufigen Codesegmenten wie zum Beispiel Konstruktoren, Destruktoren, gängigen Schleifenschreibweisen und vielem anderen mehr. Das klingt nun nicht besonders beeindruckend, kann aber eine Menge Tipperei ersparen, wie man am folgenden Beispiel sieht.
Angenommen Sie wollen eine Klasse mit einem privaten Feld ausstatten, das über einen Set- und einen Get-Property-Accessor zugänglich sein soll. Dazu geben Sie das Kürzel "prop" ein und drücken Tab. Der Quellcode-Editor erledigt dann Folgendes für Sie:
Er erzeugt ein privates Feld mit dem Namen myVar vom Typ int.
Er erzeugt einen Accessor namens MyProperty mit get und set, der ebenfalls vom Typ int ist.
Dann platziert der Editor den Cursor auf der Datentypangabe int im privaten Feld.
Ändert man den Datentyp nun in einen anderen und drückt auf Tab, wird auch der Typ des Accessors verändert. Zudem platziert der Editor den Cursor automatisch auf der Bezeichnung myVar. Nach Änderung des Namens wird er automatisch auch im Get- und Set-Teil des Accessors angepasst und der Cursor auf den Namen des Accessors gesetzt, damit man einen eigenen Namen vergeben kann.
Benötigen Sie also ein Member vom Typ double namens alter mit dem Accessor Alter, so reichen Ihnen effektiv die folgenden Zeichen aus:
Prop{Tab}double{Tab}alter{Tab}Alter
Das erzeugt dann den folgenden Code:
private double alter;
public double Alter
{
get { return alter; }
set { alter = value; }
}
Refactoring im Detail
Das Refactoring geht eine Stufe weiter als Intellisense: Im Wesentlichen handelt es sich dabei um eine Methode, mit der man den Code verändert oder umstrukturiert - meist um ihn "besser zu gestalten". Grundlegendes Wissen zum Refactoring findet sich mittlerweile in einigen Standardwerken der Literatur sowie im Web.
Visual Studio bietet die folgenden Refactoring-Methoden an:
Extract Method
Encapsulate Field
Extract Interface
Reorder Parameters
Remove Parameters
Rename
Promote local Variable to Parameter
Wie man den Bezeichnungen der Operationen leicht entnehmen kann, geht es dabei um Vorgänge, die man beim Programmieren häufig manuell durchführt.
Oft stellt man zu irgendeinem Zeitpunkt während der Entwicklung fest, dass man eine Methode oder ein Feld lieber anders nennen würde. Oder man möchte einen Datentyp verändern - aber die Methode oder der Datentyp wird bereits an vielen Stellen im Quellcode benutzt: Es bleibt also nichts anderes übrig, als ein globales Search and Replace durchzuführen und dabei zu hoffen, dass keine falschen Stellen mit ersetzt werden.
Das Refactoring "Rename" erfüllt genau die gleiche Aufgabe wie "Suchen und Ersetzen", ändert aber nur die passenden Stellen im Code.
Weitere Möglichkeiten mit Refactoring
Das Refactoring kann noch mehr: Wenn Sie beispielsweise eine Methode programmiert haben, bei der Sie nach einiger Zeit feststellen, dass eine andere Parameter-Reihenfolge eingängiger wäre, ist das bisher nicht so leicht zu korrigieren. Wenn dann die zu vertauschenden Parameter noch den gleichen Datentyp haben, stehen Sie vor einem Problem. Bei verschiedenen Datentypen würde Sie der Compiler auf alle Stellen aufmerksam machen, an denen Sie die Methode verwenden.
Letztlich bleibt Ihnen nichts anderes übrig, als zunächst die Signatur der Methode künstlich zu verändern, indem Sie zum Beispiel einen Parameter komplett entfernen. Bei der Übersetzung des Quellcodes erhalten Sie dann eine Liste aller Aufrufstellen - und diese sind manuell anzupassen, nachdem Sie die Methode wieder mit den richtigen Parametern in der neuen Reihenfolge ausgestattet haben.
Das Resultat ist, dass man diese Arbeit meist eher nicht erledigt, da sie zu aufwendig ist. Der "hässliche" Code bleibt also erhalten.
Mit Hilfe von "Reorder Parameters" ist das nicht mehr notwendig, denn da stellt das Refactoring sicher, dass nicht nur die Methode selbst, sondern auch alle Stellen, an denen die Methode aufgerufen wird, automatisch passend geändert werden.
Die anderen Refactoring-Werkzeuge sind ebenso hilfreich, genau wie die anderen Tools aus Code-Expansion. Um nur ein weiteres Beispiel zu nennen, ist es damit auch möglich, ein privates Feld automatisiert mit einem Accessor zu versehen.
Der Debugger: Besser visualisieren
Auch beim Debugger hat sich in Visual Studio viel getan: Am auffälligsten dürften dabei die so genannten Visualisierungen (Visualizers) sein. Dabei handelt es sich um Fenster, in denen komplexe Objekte besser visualisiert werden können. Beim aktuellen Visual Studio ist es so, dass alle Objekte im Watch-Fenster in Form eines Baumes dargestellt werden, wenn man den Inhalt des Objekts im Debugger betrachten will. Je komplexer ein Objekt, desto schwieriger ist es, im Baum die richtigen und gewünschten Daten aufzuspüren.
Diese Ansicht gibt es weiterhin, aber zusätzlich existiert auch die "Visualizer"-Ansicht. Gibt es für einen Typ eine oder mehrere Visualisierungen, kann man diese über das Watch-Window öffnen - und erhält eine für den Datentyp optimierte Ansicht der Daten. Für DataSet ist das zum Beispiel einfach ein DataGrid-View: Es ist also direkt aus dem Debugger möglich, die Daten in Grid-Form zu begutachten. Dabei ist man nicht auf die eingebauten Visualisierungen angewiesen, eigene Visualisierungen für Datentypen lassen sich durchaus auch zur Verfügung zu stellen.
Die nächste Version von Visual Studio ist für das Jahr 2005 zu erwarten: Sie bringt derart viele Produktivitätsverbesserungen, dass zumindest der Autor kaum noch darauf warten mag, dass die fertige Version endlich zu haben sein wird. (mha)