Vorschau: Visual C# "Whidbey"

Visual Studio 2005
Veröffentlicht: 12. Apr 2004 | Aktualisiert: 15. Nov 2004

Anmerkung Dieser Artikel wurde vor der Freigabe des Produkts verfasst. Wir können daher nicht garantieren, dass die Informationen in diesem Artikel genau mit dem gelieferten Produkt übereinstimmen. Die Angaben beschreiben das Produkt zur Zeit der Veröffentlichung des Artikels im englischen Original. Verwenden Sie diese daher nur zu Planungszwecken. Änderungen sind vorbehalten. Dieser Artikel enthält auch Links zu englischsprachigen Seiten.

Auf dieser Seite

 Einführung
 Neuerungen bei den Programmiersprachen
 Verbesserungen des Compilers
 Verbesserungen der Produktivität
 Verbesserungen des Debuggers
 Zusammenfassung

Einführung

"Whidbey" lautet der Codename für das nächste Release von Microsoft Visual Studio, das für C#-Entwickler wesentliche Verbesserungen enthält: innovative Sprachkonstrukte, neue Features für den Compiler, verbessertes Debugging und eine deutlich gesteigerte Entwicklerproduktivität. Im Bereich der Sprachneuerungen unterstützt das Whidbey-Release von C# generische Typen, Iteratoren, Teiltypen und anonyme Methoden. Durch die neuen Compilerfunktionen können Entwickler Compilerwarnungen direkt im Code deaktivieren oder die ECMA-/ISO-Standardkonformität prüfen. Whidbey enthält außerdem verschiedene Produktivitätsverbesserungen, darunter Refactoring, Codeexpansions, Codeformatierungen, verbessertes IntelliSense und vieles mehr. Die Debuggingfunktion wurde ebenfalls durch neue Features verbessert. Hierzu zählen unter anderem erweiterte Datatips, Visualizer (Sichten) im Debugger und Entwurfszeitüberprüfung von Ausdrücken. In diesem Artikel werden einige der neuen Funktionalitäten in Whidbey erläutert, denen wir weiterhin ständig neue von Kunden gewünschte Features hinzufügen.

Neuerungen bei den Programmiersprachen

Generik

Generik stellt eine der großen Erweiterungen von C# in Whidbey dar. Durch die Generik in C# können Klassen, Strukturen, Schnittstellen und Methoden über die Datentypen, die sie enthalten und bearbeiten, parametrisiert werden: generische Klassendeklarationen und generische Strukturdeklarationen. Ebenso definieren viele Schnittstellen Verträge, die über die Datentypen, die sie bearbeiten, parametrisiert werden können; generische Schnittstellendeklarationen genannt. Auch Methoden können über den Typ parametrisiert werden, um generische Algorithmen zu implementieren. Diese Methoden werden als generische Methoden bezeichnet.

Im Beispiel unten erstellen wir eine generische Stack-Klassendeklaration, wobei nach der Deklaration in spitzen Klammern ein Typparameter namens ItemType festgelegt wird. Statt Umwandlungen in und aus dem object zu erzwingen, akzeptieren Instanzen der generischen Stack-Klasse den Typ, für den sie erstellt werden, und speichern Daten dieses Typs ohne Umwandlung. Der Typparameter ItemType fungiert als Platzhalter, bis bei der Verwendung der tatsächliche Typ festgelegt wird. ItemType wird als Typ für das interne Elementarray verwendet, für den Parameter der Push-Methode und als Rückgabetyp für die Pop-Methode:

public class Stack<ItemType> 
{ 
 private ItemType[ ] items; 
 public void Push(ItemType data) {...} 
 public ItemType Pop() {...} 
}

Wenn wir, wie in dem folgenden kurzen Beispiel, die generische Stack-Klassendeklaration verwenden, können wir den tatsächlichen Typ, den die generische Klasse verwenden soll, festlegen. In diesem Beispiel weisen wir die Stack-Klasse an, den int-Typ zu verwenden, den wir durch die Notation in spitzen Klammern nach dem Namen als Typargument spezifizieren.

Stack<int> stack = new Stack<int>(); 
stack.Push(3); 
int x = stack.Pop();

Wir haben somit einen neuen konstruierten Typ erstellt, Stack<int>, für den jeder ItemType-Typparameter innerhalb der Stack-Klassendeklaration durch das bereitgestellte Typargument int ersetzt wird. Wenn wir eine neue Instanz von Stack<int> erstellen, hat der systemeigene Speicher des Elementarrays jetzt anstelle von object[] tatsächlich das int[]-Typargument und stellt eine hohe Speichereffizienz zur Verfügung. Außerdem ist beim Push von int auf den Stapel kein Boxing mehr erforderlich. Darüber hinaus müssen wir Elemente, die per Pop vom Stapel genommen werden, nicht mehr explizit in den entsprechenden Typ umwandeln, da diese spezielle Stack-Klasse bereits int in ihrer Datenstruktur speichert.

Wenn wir andere als int-Elemente in einer Stack-Klasse speichern möchten, müssen wir einen anderen konstruierten Typ von Stack erstellen und ein neues Typargument angeben. Nehmen wir an, wir haben einen einfachen Customer-Typ und möchten ihn mithilfe von Stack speichern. Wir verwenden dazu die Stack-Klasse mit der Customer-Klasse als Typargument und verwenden unseren Programmcode ganz einfach wieder:

Stack<Customer> stack = new Stack<Customer>(); 
stack.Push(new Customer()); 
Customer c = stack.Pop();

Nachdem wir nun eine Stack-Klasse mit einem Customer-Typ als Typargument der Klasse erstellt haben, können wir natürlich nur noch Customer-Objekte (oder von Customer abgeleitete Objekte) speichern. Durch die strenge Typisierung der Generik können wir Ganzzahlen nicht länger falsch im stack-Objekt speichern:

Stack<Customer> stack = new Stack<Customer>(); 
stack.Push(new Customer()); 
stack.Push(3);   // compile-time error 
Customer c = stack.Pop(); // no cast required

Teiltypen

Durch Teiltypen kann ein Typ, beispielsweise eine Klasse, auf mehrere Dateien verteilt werden. Codegeneratoren wie Visual Studio profitieren von dieser Funktion am meisten. Visual Studio generiert Code in einer anderen Datei als den Code, der vom Benutzer geschrieben wird. Auf diese Weise kann der Designer seinen Code viel leichter analysieren und neu generieren, ohne Auswirkungen auf den vom Benutzer geschriebenen Code. Ein Beispiel:

 // Form1Designer.cs 
 public partial class Form1: System.Windows.Forms.Form 
 { 
  // Designer code 
  void InitializeComponent() { … } 
 } 
 // Form1User.cs 
 public partial class Form1 
 { 
  // user code 
  void Mouse_Click(object sender, MouseEventArgs e) { … } 
 }

Anonyme Methoden
Eine anonyme Methode ist etwa die Option, einen Codeblock als Parameter zu übergeben. Im Allgemeinen können anonyme Methoden überall dort platziert werden, wo ein Delegat erwartet wird. Das einfachste Beispiel wäre etwas in dieser Art:

button1.Click += delegate { MessageBox.Show("Click"); };

Zu diesem Beispiel sind einige Punkte anzusprechen. Zunächst einmal ist es zulässig, eine Methode inline zu schreiben. Zweitens gibt es keine Beschreibung für den Rückgabetyp oder die Methodenparameter. Drittens wird der Schlüsselwortdelegat als Offset für dieses Konstrukt verwendet. Der Rückgabetyp ist nicht aufgelistet, da der Compiler ihn generiert. Das bedeutet, der Compiler weiß, was erwartet wird (EventHandler), und überprüft, ob die definierte anonyme Methode in diese Methode umgewandelt werden kann.

Haben Sie bemerkt, dass im vorigen Beispiel keine Parameter aufgelistet wurden? Der Grund ist, dass sie in diesem Codeblock nicht erforderlich sind. Wenn die Parameter verwendet werden, entsteht diese Deklaration:

 button1.Click += delegate(object sender, EventArgs e)  
   { MessageBox.Show(sender.ToString()); };

Sowohl der Typ als auch der Parametername werden angegeben.

Iteratoren
Iteratoren können insofern als logisches Gegenstück der foreach-Anweisung in C# betrachtet werden, da sie den Prozess des Durchlaufens einer Auflistung vereinfachen. Derzeit ist es sehr einfach, mithilfe des foreach-Schlüsselworts Auflistungen iterativ zu durchlaufen. Eine Auflistung zu schreiben, die foreach unterstützt, erfordert aber die Implementierung von IEnumerable- und IEnumerator-Schnittstellen sowie die Erstellung einer separaten Enumerator-Klasse/Struktur. Iteratoren verringern den Aufwand für das Erstellen dieses häufig verwendeten Codes und erleichtern Framework-Entwicklern das Offenlegen von Auflistungen. Zum Beispiel:

 class List<T>: IEnumerable<T> 
 { 
  private T[] elements; 
  public IEnumerator<T> GetEnumerator() 
  { 
   foreach (T element in elements) 
   { 
 yield element; 
   } 
  } 
 }

Achten Sie im Beispiel auf die Verwendung des neu eingeführten yield-Schlüsselworts. yield kann nur in Methoden verwendet werden, die IEnumerator, IEnumerable oder deren generische Entsprechungen zurückgeben. Iteratoren können auch als Parameter benannt und übergeben werden. In den meisten Fällen geben benannte Iteratoren aber IEnumerable anstelle von IEnumerator zurück. Zum Beispiel:

 class List<T> 
 { 
  private T[ ] elements; 
  public IEnumerable<T> Range(int from, int to) 
  { 
   while (from < to) yield elements[from++]; 
  } 
 }

Alias-Qualifizierer (Globaler Namespace-Qualifizierer)
Codegeneratoren müssen heute sicherstellen, dass der Code nicht beeinträchtigt wird, der entweder vom Benutzer geschrieben oder von einem Tool zur Codegenerierung wie Visual Studio erstellt wurde. Normalerweise empfehlen wir, die ausgegebenen Typen vollständig zu qualifizieren. Es gibt allerdings ein Problem bei der vollständigen Qualifizierung eines Typs in C#, da nicht im Stamm-Namespace nach Typen gesucht werden kann. Der globale Namespace-Qualifizierer löst dieses Problem durch die Einführung des "::" -Operators, der als Namespace- oder Typnamepräfix verwendet werden kann. Auf diese Weise können Entwickler den Stamm-Namespace ausdrücklich im Code referenzieren, wie unten dargestellt ist.

namespace Acme 
{ 
  namespace System 
  { 
 class Example 
   { 
 static void Main() 
 { 
   // In Visual Studio 2003, looking up   
   //  System.Console.WriteLine would have 
   // started in the Acme.System namespace. 
   ::System.Console.WriteLine("Hello"); 
 } 
   } 
  } 
}

Statische Klassen
Statische Klassen sollen das Entwurfsmuster des Erstellens einer versiegelten Klasse durch einen privaten Konstruktor ersetzen, der nur statische Methoden enthält. Eine statische Klasse ist durch die Platzierung des statischen Modifizierers in der Klassendeklaration gekennzeichnet. Zum Beispiel:

 public sealed class Environment  
 { 
   // Keep class from being created 
   private Environment() { } 
 }

Dieser Code kann jetzt folgendermaßen geschrieben werden:

 public static sealed class Environment 
 {   
 }

Der Vorteil einer statischen Klasse anstelle des Entwurfsmusters oben besteht darin, dass der Compiler jetzt einen Fehler melden kann, wenn Instanzenmethoden versehentlich deklariert werden.

Verbesserungen des Compilers

Inlinesteuerung von Warnungen
Als weiteres neues Whidbey-Feature können Sie steuern, ob für einen speziellen Codebereich Warnungen ausgegeben werden, indem Sie eine Direktive für den Compiler festlegen. Diese Direktive hat die vertraute Form einer #pragma-Anweisung. Unten finden Sie ein Beispiel, in dem das pragma-Schlüsselwort verwendet wird, um einen Compilerfehler für einen bestimmten Codeblock zu deaktivieren.

 #pragma warning disable 135 
  // Disable warning CS135 in this block 
 #pragma warning restore 135

Befehlszeilenoptionen
Whidbey enthält mehrere neue Optionen für den Compiler, die im Folgenden kurz beschrieben werden.

  • /warnaserror: Mithilfe der Befehlszeilenoption warnaserror in Visual Studio .NET 2003 können Entwickler alle Compilerwarnungen als Fehler behandeln. Diese Funktion wurde in Whidbey erweitert. Sie können nun steuern, welche spezifischen Warnungen als Fehler behandelt werden sollen. Das Beispiel unten zeigt, wie Sie alle Warnungen mit Ausnahme von Warnung 618 als Fehler behandeln.

     csc /warnaserror /warnaserror-:618 ...
    

  • Sie können auch eine einzelne Warnung als Fehler behandeln, wie im folgenden Beispiel dargestellt wird:

    csc "/warnaserror:1595 ...
    

  • /errorreport:<string>: Die Befehlszeilenoption errorreport steuert die Meldung von Dr. Watson für den Compiler. Weitere Informationen zu Dr. Watson finden Sie unter http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/drwatson_setup.mspx. Die folgende Liste enthält die Parameter, die für die errorreport-Option verfügbar sind.

    • /errorreport:prompt: Mit dieser Option zeigen Sie ein Dialogfeld mit Informationen zum Fehler an.

    • /errorreport:send: Mit dieser Option zeigt der Compiler bei einem internen Fehler dem Benutzer kein modales Dialogfeld an. Der Compiler fährt dennoch mit der Kompilierung fort und sendet die Fehlermeldung. Derselbe Text, der im Dialogfeld angezeigt werden würde, wird stattdessen an die Befehlszeile geschrieben.

    • /errorreport:none: Diese Option legt fest, dass keine Informationen über den Fehler an Microsoft gesendet werden. Diese Standardverhaltensweise ist die gleiche wie in Visual Studio 2002 und Visual Studio 2003.

  • /langversion:<string>: Der Hauptzweck der /langversion:<string>-Befehlszeilenoption ist, strikte Konformität mit den ECMA/ISO-Standards zu ermöglichen. Wenn für diese Option ISO-1 gesetzt ist, meldet der Compiler Fehler für alle in Whidbey eingeführten Funktionen, die nicht in diesem Standard enthalten sind.

  • /keycontainer, /keyfile, /delaysign: Diese Optionen werden verwendet, um die gleichnamigen Attribute zu ersetzen und somit eine höhere Flexibilität bei der Zuordnung von Befehlszeilenargumenten zu erzielen.

Verbesserungen der Produktivität

Refactoring

Die C# Whidbey-IDE unterstützt jetzt Refactoring. Mithilfe von Refactoring können Entwickler viele der Aufgaben, die häufig bei der Neustrukturierung von Code auftreten, automatisieren. Weitere Informationen über Refactoring finden Sie unter http://www.refactoring.com/. Mit der integrierten Refactoringfunktion können Entwickler beispielsweise die Umbenennung einer Variable im Quellcode automatisieren. Sie können zum Beispiel auch Methoden oder Schnittstellen extrahieren, Methodensignaturen ändern, Felder verkapseln oder Arraylisten ersetzen.

Im "Technical Preview" von Whidbey sind derzeit folgende Refactoringfunktionen verfügbar:

  • Extract Method

  • Rename

  • Extract Interface

  • Encapsulate Field

  • Change Method Signature

  • Replace Arraylist

Die Abbildung unten zeigt, wie Sie die Refactoringfunktionen im Code-Editor direkt über das Kontextmenü aufrufen können.

VisualCSharpWhidbey_01.gif

Abbildung 1. Menü "Refactor"

Wenn die Rename-Refactoringfunktion aufgerufen wird, wird dem Benutzer eine Änderungsvorschau im Dialogfeld Preview Changes angezeigt. Hier werden alle Stellen aufgeführt, an denen entweder Kommentar oder Code mit dem Variablennamen vorkommt. Über das Kontextmenü in diesem Dialogfeld kann der Benutzer direkt zu der Quellcodezeile springen, in der die Variable referenziert wird.

VisualCSharpWhidbey_02.gif

Abbildung 2. Vorschau der Änderungen für die Umbenennung durch die Refactoringfunktion "Rename"

Expansions

Expansions sind Codefragmente zum Vervollständigen von Code. Sie reduzieren die Anzahl der Tastenanschläge für wiederholt ausgeführte Aufgaben und vereinfachen das Hinzufügen von häufigen Konstrukten zu Ihrer Anwendung, zum Beispiel der foreach-Anweisung. Sie können auf die Expansions zugreifen, indem Sie im Kontextmenü Expansions auswählen oder diese direkt über die konfigurierbare Tastenkombination für Expansions aufrufen.

VisualCSharpWhidbey_03.gif

Abbildung 3. Expansions

Das Beispiel unten zeigt eine Codeexpansion, die die "forr"-Expansion verwendet, um eine Auflistung in umgekehrter Reihenfolge zu durchlaufen. Der Cursor wird auf den gelb hervorgehobenen Textbereich platziert, der als Platzhalter für Benutzerwerte fungiert. Im Beispiel unten durchläuft die "forr"-Expansion jedes Element in der generischen myList-Auflistung in umgekehrter Reihenfolge.

VisualCSharpWhidbey_04.gif

Abbildung 4. "forr"-Expansions

Expansions sind vollständig erweiterbare XML-Dateien, die von Benutzern angepasst oder erstellt werden können.

VisualCSharpWhidbey_05.gif

Abbildung 5. Das "XML"-Format der "forr"-Expansion

Formatieren

Quellcodeformatierung unterliegt immer persönlichen Vorlieben. Visual Studio Whidbey enthält mehrere Optionen, um die Formatierung Ihres Quellcodes vollständig anzupassen und zu steuern. Zu diesen Formatierungsoptionen gehören Klammern, Leerzeichen, Einrückung, Umbruch und Ausrichtung. Sie können auch wählen, ob die IDE den Code automatisch formatieren soll, oder nur einen bestimmten Bereich des Quellcodes. Abbildung 6 zeigt die Formatierungsoptionen für Klammern für neue Zeilen sowie eine Vorschau der gewählten Formatierungsoption.

VisualCSharpWhidbey_06.gif

Abbildung 6. Formatierungsoptionen und Vorschau

Profile

Entwickler nutzen gerne die Möglichkeit, Schriftarten, Fenster und Formatierung der IDE anzupassen. Leider ist es schwierig, mit Teamkollegen die gleichen Einstellungen zu verwenden oder die Einstellungen auf einen anderen Computer zu übernehmen. Whidbey löst dieses Problem durch einfaches Importieren und Exportieren der IDE-Einstellungen, so dass sie auf mehreren Computern und von Teamkollegen verwendet werden können.

VisualCSharpWhidbey_07.gif

Abbildung 7. Dialogfeld "Import/Export settings"

Verbessertes IntelliSense

IntelliSense wurde für generische Typen erweitert. In der Abbildung unten erkennt IntelliSense, dass myList für eine Ganzzahlenliste steht. IntelliSense stellt ein Popup mit der Information bereit, dass die Add-Methode von myList einen Ganzzahlendatentyp erwartet.

VisualCSharpWhidbey_08.gif

Abbildung 8. IntelliSense erkennt Generik

Auch für Ausnahmen wurde IntelliSense verbessert. Beim Hinzufügen eines Try-Catch-Blocks werden die verfügbaren Optionen vom Catch-Handler intelligent gefiltert, so dass nur eine Liste von Ausnahmetypen angezeigt wird.

VisualCSharpWhidbey_09.gif

Abbildung 9. IntelliSense für Ausnahmen

IntelliSense wurde ebenfalls für Attribute verbessert. Im Beispiel unten werden die verfügbaren Optionen durch das Hinzufügen eines Attributs eingeschränkt; es wird nur noch eine Liste mit Attributtypen angezeigt.

VisualCSharpWhidbey_10.gif

Abbildung 10. IntelliSense für Attribute

Farbeinstellung für Benutzertypen und Benutzerschlüssel

Beim Überprüfen von Quellcode kann zwischen Typen und Schlüsselwörtern leicht unterschieden werden, wenn sie in der IDE verschiedene Farben erhalten. Whidbey führt die eindeutige Farbkennzeichnung für Benutzertypen und -schlüsselwörter ein, um die Lesbarkeit des Quellcodes zu verbessern.

VisualCSharpWhidbey_11.gif

Abbildung 11. Verschiedene Farben für Benutzertypen und Benutzerschlüssel

Neues Buildsystem

Das Buildsystem für Whidbey wurde erheblich verbessert. Das neue Buildsystem, MSBuild, verwendet einen erweiterbaren Mechanismus, um zu beschreiben, wie ein Build erstellt wird. Benutzer können ihr eigenes Buildsystem erstellen und benutzerdefinierte, in XML geschriebene Aufgaben verwenden. Das Beispiel unten zeigt eine einfache MSBuild-Datei mit einer Kompilierungsaufgabe, die für jede Datei, die mit der Erweiterung ".cs" endet, den C#-Compiler aufruft.

- <Project> 
 <Item Type="Compile" Include="*.cs" />  
 - <Target Name="Build"> 
   <Task Name="Csc" Sources="@(Compile)" />  
 </Target> 
</Project>

Suche nach ausgeblendetem Text als Standard

Wir wurden häufig gebeten, das Standardverhalten des Dialogfelds Find and Replace (Suchen und Ersetzen) so zu ändern, dass reduzierter Text, wie zum Beispiel Text in einem Bereich, in die Suche einbezogen wird. In Visual Studio 2003 ist dieses Verhalten standardmäßig deaktiviert, während Whidbey ausgeblendeten Text standardmäßig durchsucht.

VisualCSharpWhidbey_12.gif

Abbildung 12. Beim Suchen und Ersetzen ausgeblendeten Text durchsuchen

Verbesserungen im Objektbrowser

Entwickler verwenden den Objektbrowser normalerweise, um Datentypen zu überprüfen. Viele wünschten sich aber die Möglichkeit, Ergebnisse zu filtern. Mit dem Whidbey-Objektbrowser können Sie nun Daten u.a. nach Namespace, Objekttyp oder alphabetisch filtern und sortieren.

VisualCSharpWhidbey_13.gif

Abbildung 13. Verbesserungen des Objektbrowsers

Komfortableres Andocken von Fenstern

Um die Anordnung von Fenstern in der IDE zu vereinfachen, arbeiten Sie nun mit transparenten Hilfspfeilen, mit denen Sie Fenster links, rechts oder unten in der IDE andocken.

VisualCSharpWhidbey_14.gif

Abbildung 14. Andocken von Fenstern

Automatisches Speichern in der DIE

Um Informationsverlust zu vermeiden, speichert die IDE regelmäßig Dateiwiederherstellungs-Informationen, beispielsweise falls versehentlich eine Datei geschlossen wird, ohne Änderungen zu speichern. Falls die IDE abstürzen sollte, fordert diese Sie zum Wiederherstellen der Datei auf, sobald Sie fortfahren möchten.

VisualCSharpWhidbey_15.gif

Abbildung 15. Automatisches Speichern von Dateien

Nachverfolgen von Änderungen

Das Nachverfolgen von Änderungen erleichtert die Visualisierung der Unterschiede zwischen gespeichertem und nicht gespeichertem Code. In der Abbildung unten hat der Bereich ganz links für bestimmte Codeabschnitte verschiedene Farben. Der gelb hervorgehobene Code ist neu und wurde noch nicht gespeichert. Der grün gekennzeichnete Code ist neuer Code, der gespeichert wurde. Code, der weder gelb noch grün gekennzeichnet ist, war beim Öffnen der Datei bereits vorhanden.

VisualCSharpWhidbey_16.gif

Abbildung 16. Nachverfolgen von Änderungen

Neue Windows Forms-Steuerelemente

Windows Forms für Whidbey verfügt über einige neue Steuerelemente, die von verbesserten Datensteuerelementen wie GridView über neue Steuerelemente wie das Sound-Steuerelement für Audio bis hin zum Winbar-Steuerelement für benutzerdefinierbare Menüs reichen.

VisualCSharpWhidbey_17.gif

Abbildung 17. "Winbar"-Steuerelement

Neue Web Form-Steuerelemente

ASP.NET erfuhr mehrere Verbesserungen, die die Entwicklerproduktivität entscheidend steigern. Einige dieser neuen Features sind in neuen ASP.NET-Steuerungskategorien verfügbar, u. a. Personalisierung, Sicherheit, Validierung und Navigation. Eine vollständige Liste von Visual Studio-Verbesserungen für Webentwickler finden Sie unter http://msdn.microsoft.com/asp.net/whidbey/.

Ausrichten von Steuerelementen

In Whidbey ist die Ausrichtung von Steuerelementen im Designer viel einfacher. Wenn ein Benutzer im Beispiel unten die Schaltfläche Button 2 zieht, zeigen Linien an, wie Button 1 an Button 2 ausgerichtet wird.

VisualCSharpWhidbey_18.gif

Abbildung 18. Ausrichten von Steuerelementen

Smarttags für Steuerelemente

Die Steuerelemente verfügen jetzt über Smarttags. Diese zeigen die Aufgaben an, die häufig mit dem Steuerelement verbunden sind, wie beispielsweise Formatierung und Verbindung mit einer Datenquelle.

VisualCSharpWhidbey_19.gif

Abbildung 19. Smarttags für Steuerelemente

Schnelleres Erstellen von Webprojekten

In Whidbey müssen Sie nicht länger IIS (Internet-Informationsdienste) installiert haben, um Webprojekte zu erstellen. Wählen Sie einfach eine Site aus, und erstellen Sie mit Visual Studio eine Website in einem freigegebenen Verzeichnis. Diese Website können Sie lokal ausführen und debuggen.

"Yukon"-Projektunterstützung

Visual Studio Whidbey unterstützt auch das Erstellen von Anwendungen für die nächste SQL Server-Version; Codename "Yukon".

VisualCSharpWhidbey_20.gif

Abbildung 20. Erstellen eines SQL Server "Yukon"-Projekts

Verbesserungen des Debuggers

Verbesserte Datatips

Im Debugmodus von Visual Studio .NET 2003 können Sie den Cursor über eine einfache Variable wie eine Zeichenfolge stellen, um deren Wert zu prüfen. In Whidbey wurde diese Funktion erheblich verbessert, um die Verwendung für wesentlich komplexere Typen zu ermöglichen. In der Abbildung unten zeigen die Datatips Informationen über einen komplexen Typ. Dazu gehört auch die Möglichkeit, die Typenhierarchie anzuzeigen.

VisualCSharpWhidbey_21.gif

Abbildung 21. Verbesserte Datatips

Visualizer (Sichten)

In Visual Studio .NET 2003 konnten komplexe Typen wie Datasets, Bitmaps usw. nicht auf einfache Weise direkt im Debugger angezeigt werden. Visualizer sind eine Methode, um Daten im Debugmodus visuell darzustellen. Sie können zum Beispiel die Inhalte einer XML-Zeichenfolge visualisieren, indem Sie den XML-Visualizer direkt aus dem Fenster Autos (Auto) auswählen, wie in der Abbildung unten dargestellt wird. Visualizer sind ebenfalls vollständig erweiterbar, so dass Entwickler und Komponentenprovider benutzerdefinierte Sichten für eigene Typen erstellen können.

VisualCSharpWhidbey_22.gif

Abbildung 22. Visualizeroptionen

VisualCSharpWhidbey_23.gif

Abbildung 23. XML-Visualizer

Neue Symbolserveroptionen

Wenn Sie in Visual Studio 2003 einen Symbolserver verwenden wollten, mussten Sie eine Systemumgebungsvariable wie die Folgende einrichten:

_NT_SYMBOL_PATH=srv*E:\Cache\Symbols*http://msdn.microsoft.com/download/symbols;

Und dies konnte nur vor dem Debuggen geschehen. In Whidbey haben wir eine komfortable Möglichkeit geschaffen, mehrere Symbolserverorte einzurichten und Ihren lokalen Symbolcache als Pfad einzustellen. Sie können den Symbolserver auch einrichten, wenn Sie im Unterbrechungsmodus sind. Nützlich, wenn Sie feststellen, dass die Debugsymbole noch nicht geladen wurden.

VisualCSharpWhidbey_24.gif

Abbildung 24. Symbolserveroptionen

Entwurfszeitüberprüfung von Ausdrücken

In Whidbey kann nun das Immediate-Fenster verwendet werden, um Ausdrücke zur Entwurfszeit zu überprüfen, ohne dass die Anwendung kompiliert und ausgeführt werden muss. Im Beispiel unten wird die Add-Methode direkt im Immediate-Fenster aufgerufen, ohne dass die Entwurfszeitumgebung verlassen werden muss.

VisualCSharpWhidbey_25.gif

Abbildung 25. Überprüfen von Methoden im "Immediate"-Fenster zur Entwurfszeit

Konfigurierbare Sicherheitsberechtigungen

Entwickler können ihre Anwendung mit konfigurierbaren Sicherheitsberechtigungen debuggen. Das Testen von verschiedenen Anmeldeinformationen wurde somit in Whidbey vereinfacht.

VisualCSharpWhidbey_26.gif

Abbildung 26. Konfigurierbare Sicherheitsberechtigungen

Zusammenfassung

Visual Studio Whidbey baut auf dem Erfolg von Visual Studio 2002 und Visual Studio 2003 auf und ermöglicht Entwicklern produktiveres Arbeiten als jemals zuvor. Entwickler können mit geringerem Zeitaufwand leistungsstärkere Anwendungen erstellen und sich auf das Schreiben von Code konzentrieren. Dabei helfen ihnen neue Sprachkonstrukte und Compilerfunktionen ebenso wie Verbesserungen von Produktivität und Debugger.


Anzeigen: