Seite 2: Erweiterungen, IntelliSense und Refactoring

Inhaltsverzeichnis

Neues Format für Erweiterungen

Die Aufteilung von Visual Studio 2017 in Komponenten bringt mit sich, dass es für die Visual-Studio-Erweiterungen eine neue Version 3.0 der Formats Visual Studio Integration Extension (VSIX) gibt. In ihr kann man eine Erweiterung in <Prerequisites> im Manifest definieren, von welchen Workloads sie abhängig ist.

In Visual Studio 2017 lassen sich zwar noch ältere Erweiterungen installieren, sie funktionieren aber gegebenenfalls nicht, wenn die notwendigen Workloads fehlen. Zu beachten ist, dass die Liste unter Tools | Extensions und Updates zwar Erweiterungen in älteren Formaten anzeigt, aber nur solche, die explizit deklarieren, dass sie Visual Studio 2017 unterstützen. Versuche des Autors haben ergeben, dass sich aber auch Erweiterungen problemlos installieren lassen, die Unterstützung nur für Visual Studio 2015 deklarieren. Sie muss man lediglich eigenständig aus dem Visual Studio Marketplace, bisher Visual Studio Gallery genannt, herunterladen.

Die Benutzerfreundlichkeit bei der Installation von Erweiterungen steigt, weil Anwender nicht mehr wie bisher Visual Studio nach der Einrichtung jeder einzelnen Erweiterung neu starten müssen, sondern mehrere Erweitungsinstallationen vor dem Neustart ausführen können. Die Liste der Erweiterungen verbreitet Microsoft nun über seine Cloud automatisch an alle Visual-Studio-Installationen, die mit demselben Microsoft-Account verbunden sind. Die Erweiterungen installieren sich aber nicht automatisch auf allen beteiligten Rechnern, sondern werden Benutzern lediglich unter Tools | Extensions and Updates in einer Liste "Roaming Extension Manager" angeboten. Entwickler können für jede Erweiterung das Roaming mit der Schaltfläche Stop Roaming ausschalten.

In der aktuellen RC-Version gab es im Praxistest noch einige Probleme mit der Erweiterungsinstallation. Erweiterungen erschienen auf anderen Computern erst nach einigen Minuten in der Liste. Einige weitere ließen sich dort nicht herunterladen, weil Visual Studio meldete: "could not be found on the
gallery". Installationen, die heruntergeladen werden konnten, meldeten dann aber, dass diverse laufende Visual-Studio-Prozesse (ServiceHub*.exe und PerfWatson2.exe) eine Installation verhindern, obwohl Visual Studio bereits geschlossen war. Erst nach 30 bis 60 Sekunden waren diese Prozesse beendet, und ein Klick auf Retry (s. Abb. 2) führte die Installation zum Ende.

Die neue Leichtigkeit

Zu den Neuerungen der Installation gehört auch, dass Visual Studio nicht mehr so viele Informationen in die Windows-Registry und den Global Assembly Cache schreibt. Stattdessen schreibt die IDE nun einige Konfigurationsdaten in Dateien in den Ordner /AppData/Local/Microsoft/VisualStudio und installiert die DLLs im Anwendungsordner C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise. Microsoft nennt das "Low Impact Installation" und fördert damit, dass verschiedene Visual-Studio-Versionen und sogar unterschiedliche Varianten einer IDE-Version auf einem Rechner ohne Probleme koexistieren können.

Als "Lightweight Solution Load" bezeichnet Microsoft eine Optimierung in Visual Studio 2017, bei der die geladenen Projekte zwar im Solution Explorer als Ast erscheinen, aber die Projektdatei erst geöffnet wird, wenn Entwickler das Projekt aufklappen. Dadurch wird in Projektmappen, die aus mehreren Projekten bestehen, die notwendige Initialisierungszeit für Projekte vermieden, die Entwickler gar nicht (direkt) brauchen. Sie können Lightweight Solution Load zentral für alle oder einzelne Projektmappen aktivieren. Visual Studio schlägt den Benutzern bei größeren Projektmappen die Aktivierung vor.

Im Projektmappen-Explorer können Anwender zwischen der bisher bekannten Projektansicht und einer rohen Sicht auf das Dateisystem (Folder View) umschalten. Der Solution Explorer bietet nun endlich eine eigene Suchfunktion, die mit Strg + T zu aktivieren ist (s. Abb. 3). Visual Studio 2017 öffnet dann jeweils im Editorfenster die aktuell markierte Fundstelle in der Trefferliste.

Der neue Ast "Service Capabilities" (s. Abb. 3) in einem Projekt tritt an die Stelle der erst in Visual Studio 2015 eingeführten "Connected Services". Derzeit bietet Visual Studio hier nur die Integration mit den nichtrelationalen Datenspeichern für Tabellen, BLOBs und Warteschlangen in Microsoft Azure an. Über Find more Services kann man hier zukünftig weitere Cloud-Dienste einbinden.

IntelliSense und Refactoring verbessert

Im Editor-Fenster zeigen nun sogenannte Structure Guide Lines die Einrückungstiefe besser. Dieses Feature hat Microsoft aus den Visual Studio Power Tools ins Produkt übernommen. Allerdings sind die Hilfslinien in Visual Studio 2017 nicht in verschiedenen Farben gemäß Einrückungsebene, sondern grau gestrichelt (s. Abb. 4). Derzeit profitieren nur C#-, Visual-Basic-.NET- und XAML-Entwickler davon.

Die IntelliSense-Eingabeunterstützung ist die Kernfunktion der Produktivität für Entwickler im Visual-Studio-Editor. Auch nach vielen Jahren kommt Microsoft hier noch auf neue Ideen. Entwickler können nun die Vorschlagsliste nach Sprachkonstrukttyp filtern, also nach Namensräumen, Klassen, Schnittstellen,
Enumerationen, Delegaten, Methoden, Variablennamen sowie nach Sprachschlüsselwörtern und Codeschnipselnamen (s. Abb. 5). Wer sich durch die zusätzlichen Symbole abgelenkt fühlt, kann sie unter Options | Text Editor | C# | IntelliSense | Show Completion Item Filters ausschalten.

Die Trefferliste bei der altbekannten Funktion "Find all References" ist nun übersichtlicher, weil die Ergebnisse nach verschiedenen Kriterien wie Projektname, Dateiname und Typname gruppierbar sind. Ergebnisse mehrerer Suchvorgänge können sich Entwickler nun parallel anzeigen lassen. Auch die Funktion "Goto Line" (Strg + G) ist kein modaler Dialog mehr, sondern schmiegt sich wie die Volltextsuche in die obere rechte Ecke des Editors ein. Über das neue Eingabefeld kann man auch Dateien, Typen und Mitglieder per Namenssuche finden.

Das Refactoring von Programmcode unterstützt die IDE nun mit weiteren Vorschlägen in der mit Visual Studio 2015 eingeführten Glühbirne:

• Extrahieren von Klassen in eigenständige Dateien, wenn der Name der Klasse nicht zum Dateinamen passt
• Umwandeln von Properties in Methoden
• Hinzufügen geschweifter Klammern zu if-Bedingungen mit einzeiligen Anweisungen
• Umbau sequenzieller Objektinitialisierungsbefehle in die Object-Initializer-Syntax, die Microsoft 2008 mit C# 3.0 eingeführt hatte
• Konvertierung von String.Format in die in C# 6.0 eingeführte String-Interpolation-Syntax (das war in Visual Studio 2015 als Teil der kostenfreien Erweiterung "C# Essentials" verfügbar)
• Bei switch-Anweisungen fügt Visual Studio auf Wunsch einen fehlenden default-Block hinzu. Bei der Fallunterscheidung für Aufzählungstypen lassen sich fehlende case-Werte einfügen
• Nutzung der in C# 7.0 vorgesehenen Inline Variable Declaration: Int32.TryParse(eingabe, out int i)
• Nutzung der Fehlererzeugung mit throw in Verbindung mit dem Null Coalescing Operator (??), zum Beispiel throw new ApplicationException()

Stark erweitert hat Microsoft die "Code Style"-Regeln, die Entwickler in den Text-Editor-Optionen für C# und Visual Basic einstellen können. Bisher gab es nur vier Regeln zum Einsatz von this/Me, var/Dim und der Verwendung von .NET-Klassennamen (z. B. Int64) anstelle von sprachspezifischen Typnamen (long). Nun können Entwickler diese Optionen situationsbezogen steuern und zudem Namensregeln definieren, die der Editor schon bei der Eingabe prüft und gegebenenfalls bemängelt.

Namensregeln lassen sich für zahlreiche Bezeichnerarten (Klassen, Schnittstellen, Properties, Methoden, Enumerationen usw.) auch abhängig von den verwendeten Sichtbarkeiten (public, private, protected, internal) steuern. So können Entwickler für private Klassen andere Namensregeln als für öffentliche vorsehen. Bei den Namensregeln sind Art der Groß-/Kleinschreibung (Pascal Casing, Camel Casing, First Word Upper, All Upper, All Lower), Pre- und Suffixe sowie Worttrennzeichen einstellbar.