Heißes Nachladen und mehr

Visual Studio 2022 bietet auch Neuigkeiten im Bereich Test und Debugging. Das bekannteste Feature ist sicherlich Hot Reload. Wer die beiden vorangegangenen Artikel in diesem Heft gelesen hat, kennt die zahlreichen Stellen bereits, die Microsoft angepasst oder komplett erneuert hat. Dieser Ar­tikel wirft einen Blick auf das Testen und Debuggen von Quelltext. Dafür sollte eine Entwicklungsumgebung einen ordentlichen Support bieten, da ansonsten Fehler übersehen werden können oder diese Aufgaben länger dauern, als sie müssten. Visual Studio 2022 konzentriert sich in diesem Feld auf Anpassungen in den Bereichen Debugging, Diagnostics, Testing Tools, Performance-Messungen und das Hot Reload genannte Feature, über das bereits viel diskutiert wurde.

Debugging und Diagnostics

Für das Debugging von Code und die Analyse von Anwendungen wurden hier und da ein paar Einstellungen und Dialoge angepasst und verbessert. So ist der Dialog zum Anhängen an einen Prozess jetzt benutzerfreundlicher gestaltet. Tritt eine Ausnahme auf, wird jetzt ein sogenannter Exception Helper im catch-Block angezeigt (Bild 1). Dadurch lässt sich der Hilfetext mit den relevanten Informationen zur Ausnahme anzeigen. Wer Code laufen lassen möchte, ohne dass Breakpoints dazwischenfunken, findet einen neuen Menüpunkt namens Force Run to Click. Diese Option lässt den Debugger so lange laufen, bis die ausgewählte Cursor-Position erreicht ist. Zu dieser Funktion existiert auch eine Quick Action, die neben einer Codezeile angezeigt wird, wenn sich die Maus bei zugleich gedrückter Umschalttaste über dieser Zeile befindet.

Neuigkeiten gibt es auch bei der Analyse von Memory-Dumps. Deren Analyse wurde dahin­gehend verbessert, dass jetzt mehr Sync-over-Async-Probleme in ASP.NET-Core-Speicherabzügen gefunden werden. Auch die Analyse, welche Teile des Codes die meisten CPU-Ressourcen verbrauchen, wurde verbessert. Die Analyse sucht die Top-5-­Threads nach CPU-Zeit. Ist der Grund für den Absturz gar nicht bekannt, lässt sich der Exception Analyzer nutzen, um schnell alle Ausnahmen auf dem Heap zu finden und zu überprüfen. Bei der Heuristik des Finalizer Queue Analyzers gibt es ebenfalls eine interessante Änderung: Dieser Analyzer konzentriert sich jetzt auf den vom Entwickler geschriebenen Code und schließt Objekte aus, die vom .NET Framework verwaltet werden.Beim Thema Breakpoints hat sich ebenfalls einiges getan. Es wurde beispielsweise ein neuer Breakpoint-Typ namens Dependent Breakpoint eingeführt. Der neue Haltepunkt erlaubt es, einen Haltepunkt so zu konfigurieren, dass er nur aktiviert wird, wenn zuvor ein anderer Haltepunkt aktiv wurde. Die Bedingung ist also nicht in Abhängigkeit von Code oder Daten formuliert, sondern hängt von anderen Breakpoints ab. Beim Debuggen hält der Visual Studio Debugger die Anwendung nur dann am abhängigen Haltepunkt an, wenn der vorausgesetzte Haltepunkt ebenfalls aktiv war. Die Konfiguration ist denkbar einfach: Erfreulicherweise lässt sich jeder Haltepunkt in einen abhängigen Haltepunkt umwandeln, indem das Kontrollkästchen mit der Abhängigkeit in den Einstellungen eines Breakpoints aktiviert wird. Anschließend lässt sich der vorausgesetzte Haltepunkt aus einem Dropdown-Menü auswählen, siehe Bild 2. Das ist schnell gemacht und funktioniert auch nachträglich bei vorhandenen Breakpoints.

Um Haltepunkte besser einfügen zu können, gibt es jetzt eine visuelle Hilfestellung (Glyph), die deutlich macht, an welchen Positionen ein Breakpoint möglich ist. Über einen Rechtsklick öffnet sich ein neues Menü, um verschiedene Breakpoints (Conditional, Tracepoint, Temporary Breakpoint) einzufügen. Der Temporary Breakpoint ist ebenfalls neu. Mit ihm lässt sich der Code nur einmal unterbrechen. Beim Debuggen hält der Visual Studio Debugger die Laufzeit der Anwendung ganz normal an, entfernt den Breakpoint aber sofort wieder, nachdem er aktiviert wurde. Jeder Haltepunkt lässt sich in einem temporären umwandeln. Dafür gibt es in den Einstellungen ein entsprechendes Kontrollkästchen.Breakpoints zu setzen, zu entfernen und erneut zu setzen, wenn sie an der falschen Stelle waren, ist häufig nervig. Mit Visual Studio 2022 lassen sich die Haltepunkte per Drag-and-drop verschieben. Hat der Breakpoint eine Abhängigkeit zum Code, funktioniert dieses Verschieben so lange, wie zum Beispiel die Variable im Kontext der neuen Position des Breakpoints bleibt. Eine gute und übersichtliche Funktion ist der neue Eintrag Externe Quellen im Solution Explorer, wenn sich Visual Studio 2022 im Debug-Modus befindet. In diesem Bereich werden Quellen für verwaltete Module mit geladenen Symbolen angezeigt, die Source-Server- oder Source-Link-Informationen enthalten, siehe Bild 3.

Während der Fehlersuche wird jede geladene verwaltete Symboldatei (Dateierweiterung .pdb) unter diesem Eintrag im Solution Explorer angezeigt, die Source-Server-Informa­tionen enthält. Wie in jedem anderen Projektmappen-Explorer-Ordner auch lässt sich nach Dateien suchen oder auf ein Element doppelklicken, um die Datei vom Source Server herunterzuladen und sie im Visual-Studio-Editor zu öffnen.

Test-Tools

Bei den Test-Tools gibt es einige Veränderungen, eine Reihe davon wurden von der Community dringend gefordert. Zum Beispiel die Aktion Show in Test Explorer. Damit ist die Möglichkeit gemeint, von der Stelle, an der sich der Cursor in einer Testmethode im Editor befindet, zur Stelle des Tests im Test Explorer zu springen. Das ist ähnlich zur Funktion Sync with Active Document, die das gerade aktive Dokument im Solution Explorer hervorhebt. Der Web Load Test Recorder ist nun in Visual Studio 2022 verfügbar. Allerdings gibt es auch eine schlechte Nachricht, denn der Coded UI Test-Recorder wird nicht in Visual Studio 2022 enthalten sein. Es besteht zwar weiterhin die Möglichkeit, Coded-UI-Tests in Visual Studio 2022 auszuführen und neue Tests zu erstellen, jedoch ist der Rekorder auf 32-Bit-Abhängigkeiten angewiesen, die laut Microsoft nicht portiert werden können. Wer dringend auf den Rekorder angewiesen ist, muss Visual Studio 2019 ­parallel installieren, was sich eher wie ein schmutziger Workaround anhört als wie eine praktikable Lösung. Vielleicht ist dieser Weg in den ersten Monaten des Umstiegs akzeptabel, aber ab einem gewissen Punkt der Migration sollte die ältere Version obsolet sein. Generell gilt aber immer noch die wichtige Info, dass der Web Load Test [1] und der Coded UI Test [2] seit 2019 als veraltet gelten und Microsoft plant, die Funktionen aus dem Produkt zu entfernen, sobald die Auswirkungen minimiert werden können – was immer das in der Praxis auch heißen mag. Microsoft empfiehlt allen, die Web-UI-Tests benötigen, dafür ein plattformübergreifendes und quelloffenes Framework zu nutzen. Die Empfehlung lautet aktuell, Playwright [3] zu verwenden. Das Framework unterstützt alle wichtigen Browser und bietet eine wesentlich bessere Handhabung von asynchronem Code. Zudem ist eine integrierte Testaufzeichnungsfunktion vorhanden. Zu den Test-Tools gibt es eine gute Übersichtsseite in der Dokumentation zu Visual Studio 2022 [4]. Diese wurde für die neue Version angepasst, sodass Einführung und Tutorials weitere offene Fragen beantworten.

Hot Reload

Mitte Mai 2021 wurde das Feature Hot Reload für .NET angekündigt [5]. Mit Hot Reload lässt sich der Quellcode einer Anwendung ändern, während diese läuft, ohne dass die Ausführung manuell pausiert oder ein Haltepunkt gesetzt werden muss. Über die Schaltfläche Codeänderungen anwenden in Visual Studio lassen sich Änderungen übernehmen, während die Anwendung läuft. Hot Reload funktioniert mo­mentan mit Projekten für WPF, Windows Forms, .NET MAUI, ASP.NET-Core-Apps (Code-behind), ­Konsolenanwendungen und zahlreichen weiteren. In Zukunft soll diese Liste noch ­erweitert werden.Auch wenn die Reise von Hot Reload bereits mit einer Preview in Visual Studio 2019 startete, soll der vollumfängliche Support laut Microsoft erst mit Visual Studio 2022 gegeben sein. Im finalen Release von Visual Studio 2022 wurde das Feature Hot Reload für .NET und C++ deutlich überarbeitet. Das neue Icon mit dem Dropdown-Menü heißt jetzt auch Hot Reload und bietet einige Optionen, etwa den Restart einer Anwendung und allgemeine Einstellungen zum Hot-Reload-Feature. Ebenfalls überarbeitet und finalisiert wurden die unterstützten Szenarien, in denen Hot Reload überhaupt zur Verfügung steht.Beim Arbeiten mit Visual Studio 2022 und einer gestarteten Anwendung mit Debugger funktioniert Hot Reload mit den meisten Versionen des .NET Frameworks, .NET Core und .NET 5+. Bei der Verwendung von Visual Studio 2022 ohne Debugger ist Hot Reload auch für die meisten Arten von .NET-6-Anwendungen verfügbar. Das umfasst auch andere neue Funktionen, wie die Unterstützung für Hot Reloading von Blazor-Projekten und generell das Bearbeiten von Razor-Dateien in ASP.NET-Core-Anwendungen und Hot Reload für CSS. Wird Visual Studio 2022 zusammen mit einer Anwendung für .NET 6 genutzt, steht laut Microsoft das leistungsstärkste Hot-Reload-Feature zur Verfügung.Bei der Kombination von Visual Studio 2022 und .NET 6 werden viele Projekttypen und Szenarien unterstützt. Einige dieser Möglichkeiten sind unter anderem Blazor-Anwendungen (Server und WebAssembly), Razor-Dateibearbeitung sowohl in Blazor- als auch in regulären ASP.NET Core-Web­sites, CSS-Hot-Reload und Hot-Reload-Unterstützung beim Ausführen von Anwendungen ohne den Debugger. Unter ASP.NET Core werden einige Szenarien in Kombination mit .NET 6 unterstützt, die in der Zukunft deutlich ausgebaut werden sollen.Hot Reload unter .NET wird durch den bekannten Mechanismus „Bearbeiten und Fortsetzen“ abgebildet. Dieses Feature wurde erweitert, um zusätzliche Bearbeitungen zu unterstützen. Diese Verbesserungen sind unter anderem das Hinzufügen, Aktualisieren oder Löschen von benutzerdefinierten Attributen, das Hinzufügen oder Aktualisieren von Record-Strukturen, das Hinzufügen oder Aktualisieren von #line-Direktiven, das Bearbeiten von Switch-Ausdrücken und Dateien mit #line-Direktiven, einschließlich Änderungen an der Direktive selbst. Zusätzlich das Editieren von Top-Level-Anweisungen, das Bearbeiten von Code, der eines der neuen C#-10-Features verwendet, und das Umbenennen von Parametern bestehender Methoden. Diese Neuerungen sind nicht nur für Hot Reload verfügbar, sondern auch für das bekannte Bearbeiten und Fortsetzen.Zu den Performance-Messungen in VS 2022 gibt es ebenfalls eine gute Übersichtsseite [6]. Diese erklärt die Grundlagen und zeigt Tutorials für Szenarien von Performance-Messungen und ist eine weitere wichtige Grundlage für das Debugging und die Diagnose in Visual Studio.

Remote Testen

Das Testen auf einem Remote-System steht in der ersten experimentellen Preview zur Verfügung. Diese Vorschau zeigt die Möglichkeit, Tests in entfernten Umgebungen wie Linux-Containern, WSL und über SSH-Verbindungen auszuführen. Die erste Vorschauversion ist dazu gedacht, Feedback aus der Community zu sammeln. Eine der Anforderungen für die Verwendung dieser experimentellen Version von Remote Testing ist unter anderem, dass die Zielumgebung alle Voraussetzung zur Verfügung stellen muss. Soll beispielsweise die Nutzung von .NET 3.1 getestet werden, muss auch das entfernte Ziel .NET 3.1 installiert haben. Aktuell werden nur .NET-Szenarien unterstützt. Eine Erweiterung auf C++ ist laut Micro­soft geplant. Die Release Notes zur Version 1.7.0 enthalten in einem eigenen Abschnitt [7] eine vollständige Auflistung von Anforderungen, wie dieses Feature aktiviert werden kann und was momentan unterstützt wird und was nicht.

Trusted Locations

Das Feature der Trusted Locations ist vermutlich eher unter der Bezeichnung Vertrauenseinstellungen bekannt. Damit gemeint ist, dass beim Öffnen von Dateien und Ordnern geprüft wird, ob diesen Quellen vertraut werden kann oder nicht. Das soll das Bewusstsein für die Risiken beim Umgang mit unbekanntem Code verbessern, da Software immer häufiger das Ziel von Angriffen ist und das Einschleusen von Schadsoftware bereits während der Entwicklung, zum Beispiel bei Repositories, beginnt.Beim Überarbeiten dieser Einstellungen wurde die Prüfung Mark of the web entfernt und ein Warndialog hinzugefügt, der angezeigt wird, wenn versucht wird, Code in Dateien, Projekten oder Ordnern zu öffnen, denen zuvor nicht vertraut wurde. Code kann nun im aktuellen Ordner oder im übergeordneten Ordner als vertrauenswürdig eingestuft werden. Vom Benutzer erstellte Projekte werden automatisch zur Liste der vertrauenswürdigen Speicherorte des Benutzers hinzugefügt. Bevor Inhalt, wie zum Beispiel eine Solution, ein Projekt, eine Datei oder ein Ordner, in der Entwicklungsumgebung geöffnet wird, wird überprüft, ob der Speicherort des Ordners zuvor als vertrauenswürdig eingestuft wurde. Wird nicht vertrauenswürdiger Code erkannt, warnt davor ein entsprechender Dialog. Diese Funktion ist allerdings derzeit im Standard deaktiviert und kann in den Einstellungen von Visual Studio 2022 aktiviert werden.

Windows Subsystem for Linux WSL 2 für C++

Mit dem Windows Subsystem für Linux in Version 1 ist es bereits möglich, C++-Code auf WSL-1-Distributionen zu erstellen und zu debuggen, indem das native WSL-1-Toolset zum Einsatz kommt. Dieses Toolset wurde in Visual Studio 2019 Version 16.1 eingeführt.WSL 2 ist die neue, empfohlene Version dieses Subsystems, die unter anderem eine bessere Leistung des Linux-Datei­systems und eine GUI-Unterstützung bietet. Mit dem WSL-2-Toolset von Visual Studio 2022 lässt sich C++-Code auf WSL-2-Distributionen von Visual Studio aus erstellen und ­debuggen, ohne dass eine SSH-Verbindung erforderlich ist.Das WSL-2-Toolset unterstützt sowohl CMake- als auch MSBuild-basierte Linux-Projekte. CMake wird jedoch von Microsoft für die plattformübergreifende C++-Entwicklung mit Visual Studio empfohlen, da es ermöglicht, dasselbe Projekt auf Windows-, WSL- und Remote-Systemen zu erstellen und zu debuggen. Die Integration von CMake kann in den Einstellungen von Visual Studio aktiviert werden.

Fazit

Auch im Bereich des Testens und Debuggings bietet Visual Studio 2022 einige Neuerungen und Verbesserungen. Diese beziehen sich eher auf viele kleine, weit verstreute Stellen in der Entwicklungsumgebung. Die beiden vorangegangenen Artikel in dieser Ausgabe haben gefühlt mehr neue und vollständige Funktionen zu bieten.Dennoch sind Änderungen beim Debugging nicht minder wichtig. Es ist zu erwarten, dass zum Beispiel Hot Reload noch viele Updates erhalten wird. Auch die Änderungen an den Breakpoints und Test-Tools sind wichtige Neuerungen für Visual Studio 2022.Die neue Version von Visual Studio lohnt sich auch hinsichtlich der neuen Funktionen fürs Testen und Debugging. Wahrscheinlich für die meisten deswegen, weil in dieser Version Hot Reload in Kombination mit .NET 6 genutzt werden kann. Wer nicht auf andere Entwicklungsumgebungen setzen möchte, ist hier an die neue Version gebunden. 

Fussnoten

1. Informationen zum Web Load Test in Visual Studio, http://www.dotnetpro.de/SL2204VSTesten1
2. Informationen zu Coded UI Tests in Visual Studio, http://www.dotnetpro.de/SL2204VSTesten2
3. Website zu Playwright, https://playwright.dev
4. Informationen zu Test-Tools in der VS-2022-Dokumenta­tion, http://www.dotnetpro.de/SL2204VSTesten3
5. Offizielle Ankündigung des Hot-Reload-Features, http://www.dotnetpro.de/SL2204VSTesten4
6. VS 2022: Übersichtsseite zu Performance-Messungen, http://www.dotnetpro.de/SL2204VSTesten5
7. Anforderungen fürs Remote-Testen, http://www.dotnetpro.de/SL2204VSTesten6