Seite 3: Fehlersuche, XAML und .NET Core

Inhaltsverzeichnis

Produktivere Fehlersuche

Beim Debugging in Visual Studio bot die Entwicklungsumgebung bisher bei aufgetretenen Laufzeitfehlern für Native Code und Managed Code zwei Dialoge, die nicht alle Informationen (z. B. eingebettete Exception-Objekte) auf einen Blick, sondern erst nach zum Teil mehreren Mausklicks zeigten. Microsoft hat in Visual Studio 2017 nun einen neue "Exception Helper"-Sprechblase eingeführt, die innere Fehler direkt anzeigt (s. Abb. 6).

Bei dem häufigen NullReference-Fehler zeigt der Exception Helper jetzt das verursachende Objekt an – allerdings leider nicht, wenn es ein innerer Fehler ist (s. Abb. 7). Lästig war in bisherigen Visual-Studio-Versionen, dass die Fehleranzeige beim Debugging teilweise erst mit einigen Sekunden Verzögerung erschien. In Visual Studio 2017 geht es wesentlich schneller.

Beim Anfügen des Debuggers an laufende Prozesse gibt es nun ein Suchfeld. Mit der Tastenkombination Shift + Alt + P können Entwickler den Debugger an den zuletzt verwendeten Prozess erneut anheften, wenn es noch einen gleichnamigen Prozess gibt. In Webprojekten ist das durchgängige Debugging vom Webserver zum JavaScript im Browser nun in Verbindung mit Googles Chrome auch ohne den Umweg über Attach Process möglich. Vorher konnten Entwickler das nur mit dem Internet Explorer.

Eine weitere Verbesserung im Debugger ist die Option, die Verhaltenseinstellung bei Laufzeitfehlern an Bedingungen zu binden. Derzeit ist jedoch nur eine Bindung an den Modulnamen möglich. Die Verwendung eines Auswahlfelds an der Stelle deutet aber darauf hin, dass Microsoft hier zukünftig auch andere Bedingungsarten anbieten will.

Mit "Live Unit Testing" sehen Entwickler im Editor schon während der Programmcodeeingabe durch Symbole für jede Programmzeile (s. Abb. 7), ob diese durch einen Unit-Test abgedeckt ist und ob der Test erfolgreich war. Die von ihnen definierten Unit-Tests werden laufend im Hintergrund ausgeführt. Als Testframework können nicht nur MSTest, sondern auch NUnit und XUnit zum Einsatz kommen. Live Unit Testing ist aber aktuell nur verfügbar für Projektmappen, in denen es lediglich C#- und/oder Visual-Basic-.NET-Projekte gibt. .NET Core wird noch nicht unterstützt.

XAML im laufenden Betrieb ändern

.NET-Code können Nutzer schon länger während des Debuggings ändern, ohne den Programmfluss zu beenden und die Anwendung neu zu starten. Diese Edit & Continue-Funktion dehnt Microsoft nun auf die Oberflächenbeschreibungssprache XAML (Extensible Application Markup Language) aus, sodass Entwickler direkt die Auswirkung von Änderungen in der Benutzeroberfläche beobachten können. Zudem bietet Microsoft erstmals Refactoring-Funktionen für XAML-Code an. Dazu gehören das automatische Einfügen von Namensräumen, die Umbenennung der Namensraum-Präfixe, das alphabetische Sortieren der Namensräume und die Entfernung nicht verwendeter Namensräume aus der XML-Deklaration. Diese Features gibt es für XAML in WPF und Universal Windows 10 Apps (UWA), nicht aber für das ausgemusterte Silverlight und das neue Xamarin Forms.

Für Xamarin Forms, eine XAML-Variante für iOS-, Android- und Windows-10-Apps, die Entwickler bisher immer komplett manuell im Tag-Editor erfassen mussten, gibt es nun eine grafische Vorschau des Ergebnisses in der Entwicklungsumgebung. Die grafische Gestaltung, die Entwickler von WPF, Silverlight oder UWA gewohnt sind, ist für eine Xamarin-Forms-Oberfläche weiterhin nicht möglich. Eine aus anderen XAML-Varianten bekannte Funktion der Analyse und Veränderung des XAML-Steuerelementbaums zur Laufzeit ist nun für Xamarin-Apps unter dem Namen Xamarin Inspector in Visual Studio 2017 enthalten.

.NET Core in Visual Studio 2017

Wie der Vorgänger unterstützt Visual Studio 2017 die .NET-Versionen 2.0 bis 4.6.2. Der Support für .NET Core 1.x ist als Workload installierbar. Dabei kommt die dritte Preview des .NET Core SDK zum Einsatz, die nicht mehr auf .xproj- und project.json-Dateien basiert, sondern eine neue Version der XML-basierten MSBuild-Dateien (.csproj) verwendet, die auch alle Referenzen zu NuGet-Paketen enthalten. Mit dem neuen Format sind zudem Referenzen zwischen .NET-Core-Projekten und anderen .NET-Projektarten (z. B. Xamarin-Projekte) möglich.

Bestehende .xproj- und project.json-Dateien konvertiert Visual Studio 2017 beim Öffnen des Projekts in .csproj-Dateien, wobei das noch nicht zuverlässig funktioniert. Entwickler müssen zudem bedenken, dass es keine Option zur Rückkonvertierung gibt, falls sie später doch mit dem JSON-Format oder Visual Studio 2015 weiterarbeiten möchten. Microsoft spricht dabei von der Alpha-Version der "MSBuild-based .NET Core Tools", die Teil des .NET Core SDK 1.0 Preview 3 sind und auf .NET Core 1.1 RTM basieren. Für das neue plattformübergreifende .NET gibt es vorerst einige funktionale Einschränkungen, zum Beispiel kein Live Unit Testing. Mit der endgültigen Version von Visual Studio 2017 sollen die .NET-Core-Werkzeuge erstmals den RTM-Status erreichen.

Auch im neuen Visual Studio for Mac, einer erweiterten Version von Xamarin Studio, können Entwickler mit .NET Core 1.1 und der Preview 3 des SDK arbeiten. Visual Studio for Mac ist am 16. November 2016 als Preview erschienen.

Ein neuer Versuch für JavaScript-IntelliSense

Für JavaScript-Entwickler versucht Microsoft alle Jahre wieder, die IntelliSense-Eingabeunterstützung zu verbessern, was aufgrund der schwachen Typisierung schwierig ist. Der neueste Ansatz verwendet im Hintergrund TypeScript-Typdefinitionsdateien, selbst wenn Entwickler gar nicht TypeScript benutzen
wollen. Die Definitionen dienen dann nur zur Entwicklungszeit in Visual Studio dazu, die Eingabeunterstützung anzubieten. Basis dafür ist ein neuer JavaScript Language Service mit dem Projektnamen Salsa. Neben Salsa und der Tatsache, dass Microsoft TypeScript 2.1 mit Visual Studio 2017 ausliefert, hat sich für Webentwickler in der neuen Version nichts Wesentliches getan.