Seit der Umstellung von Visual Studio auf Continuous Delivery gilt, dass der Zustand „vor dem Update“ und der Zustand „nach dem Update“ Singularität erreicht haben. Wir geben einen kurzen Überblick über neue Aspekte und Funktionen, die .NET-Entwickler:innen dabei helfen, Zeit und Geld zu sparen.
Zum Geleit: Die folgenden Experimente erfolgen, wie immer, unter Nutzung einer Preview-Version von Visual Studio Community 2022. Wer aus Gründen von Stabilität oder Haftung nicht mit Preview-Versionen arbeiten kann, sollte im Hinterkopf behalten, dass die normale Visual-Studio-Version in Tests des Autors im allgemeinen problemlos mit einer Preview-Version auf der gleichen Workstation koexistieren kann.
Als Host kommt hier ein MSI GF 65 zum Einsatz. Die praktische Erfahrung lehrt, dass insbesondere AI-basierte IntelliSense-Funktionen der integrierten Entwicklungsumgebung nur vergleichsweise wenig parallelisiert sind und von hoher Einkernrechenleistung stark profitieren.
Microsoft pflegt die mit Version 17.4 erstmals eingeführte ARM64-Version von Visual Studio auch in Version 17.6 weiter. Nach Ansicht des Autors ist ihre Nutzung auf Low-End-Prozessrechnern wie einem Raspberry Pi 4 wenig sinnvoll. Die Achtkernworkstation des Autors ist wesentlich schneller, legt aber auch schon erhebliche Denksekunden ein.
Angemerkt sei, dass die ARM64-Variante in Version 17.6 eine wichtige Erweiterung erhält: Die Unterstützung für das neue GUI-System MAUI steht nun nicht mehr nur auf x64-Installationen, sondern auch für ARM64 als Preview zur Verfügung.
Der wohl wichtigste Grund für Visual Studio ist, dass das Editieren von Code in einer integrierten Entwicklungsumgebung samt IntelliSense bequemer von der Hand geht als in einem Texteditor. Die erste Erweiterung betrifft die Bearbeitung von Android-Manifest-Dateien. Was bisher (und im Google-Ökosystem klassisch) unter Nutzung eines XML-Texteditor erfolgte, ist in Visual Studio 17.6 P2 unter Nutzung eines grafischen Frontends möglich.
Die praktische Erfahrung des Autors im Bereich der Android-Entwicklung lehrt allerdings, dass der Benefit vergleichsweise gering sein dürfte. In der Praxis sind die Möglichkeiten zur Bearbeitung der Android-Manifest-Datei nämlich fast unbegrenzt und nur schwer in einer einzelnen Benutzerschnittstelle zu erfassen. In der Praxis ist es außerdem denkbar, dass es – insbesondere bei komplexen Manifest-Dateien – mitunter zu Beschädigungen an von Hand erzeugten Kompilationen kommt: Schon zu Zeiten von Symbian und Carbide.c++ galt, dass man sich Probleme erspart, wenn ein Versionskontrollsystems mitläuft.
Erweiterung Nummer zwei ist die Colorisierung von geschwungenen Klammern und ähnlichen Elementen. Nutzer der Programmiersprachen C#, TypeScript, JavaScript, Visual Basic und Razor können diese Funktion manuell freischalten. Öffnen Sie hierzu das Fenster Tools | Options | Environment | Preview Features, und aktivieren Sie die Checkbox Enable Brace Pair Colorization. Lohn der Mühen ist dann das in Abbildung 1 gezeigte Einfärben von Klammern und ähnlichen Elementen, was zu einer Steigerung der Übersichtlichkeit führt.
Abb. 1: Visual Studio: jetzt mehrfarbig
Interessant ist außerdem die Möglichkeit, Beispielcode für Funktionen direkt im Editor zu laden. Hierzu reicht es aus, den Cursor auf dem Element abzulegen und zu warten, bis das normale IntelliSense-Fenster mit Informationen erscheint. Das Anklicken des neuen Links GitHub Examples and Documentation startet dann die Suche in den öffentlichen GitHub-Repositorys, um das markierte Element en vivant vorzuführen.
Nutzer:innen von C++ in Visual Studio (Stichwort: Spiele und Embedded) können Member-Funktionen nun bequemer erzeugen. Wer eine Klasse mit Feldern lädt, findet unter dem Klassennamen drei Punkte.
Wer dieses anklickt, kann ein Kontextmenü öffnen, dass die Erzeugung verschiedener Member-Funktionen erleichtert. Neben der Erzeugung von Konstruktoren unterstützt Microsoft hier auch die Realisierung von Vergleichsoperatoren. Bei Bedarf kümmert sich Visual Studio auch darum, alle Member-Variablen als Parameter der generierten Funktionen zu exponieren.
Eine weitere nette Erweiterung für C++- und Spiele–entwickler:innen betrifft die Shader-Beschreibungssprache HLSL. Das bisher entwickelte Plug-in [1], das Visual Studio um verschiedene Komfortfunktionen bei der Bearbeitung von HLSL-Shadern unterstützt, ist nun direkter Bestandteil der integrierten Entwicklungsumgebung. Wer die Payloads Game development with C++ oder Game development with Unity verwendet, kann das Modul über die Rubrik HLSL Tools direkt im Visual Studio Installer deployen.
Wer damals von Palm OS auf Windows Mobile umstieg (und kein englisches Windows verwendete), profitierte immens von der Verfügbarkeit eines integrierten Debuggers. Schon zu Zeit von Visual Basic 6 galt, dass die Fehlersuche in Microsofts IDE einfach wesentlich bequemer von der Hand ging. Mit Visual Studio 17.6 erweitert Microsoft die Fehlersuchsysteme an vielerlei Stellen.
Dass Visual Studio die Inhalte von IEnumerable- und DataSet-Objekten über einen dedizierten Visualizer bequemer erfassbar macht, ist seit einigen Versionen bekannt. Neu ist, dass diese Funktion nicht mehr nur beim lokalen Debugging zur Verfügung steht. Wer ein unter Unix laufendes .NET-Programm per Remote Debugging oder in einem Docker-Container analysiert, kann diese Funktion nun ebenfalls zur Fehlersuche und -analyse heranziehen.
Eine weitere Komfortsteigerung betrifft Breakpoints: Insbesondere in Embedded-Systemen gilt, dass je nach zu erfüllender Aufgabe unterschiedliche Breakpoint-Konfigurationen erforderlich sind, die sich teilweise gegenseitig ausschließen. Platziert man im Rahmen der Kommutator-Ansteuerung einen Breakpoint, muss man sich nicht wundern, wenn der „angehaltene“ Motor durchbrennt.
Bisher war zur Umgehung dieses Problems manuelles Ein- und Ausschalten der verschiedenen Breakpoint-Gruppen erforderlich. In Preview 2 ist es möglich, wie in Abbildung 2 gezeigt, Gruppen von Breakpoints anzulegen (Kasten: „Im Offenen entwickelt“). Diese lassen sich danach gebündelt ein- oder ausschalten, was in der Praxis logischerweise wertvolle Zeit einspart.
Abb. 2: Gruppierte Breakpoints sind einfacher verwaltbar (Bildquelle: Microsoft)
Die Funktion zur Gruppierung von Breakpoints ist ein Paradebeispiel für Microsofts Nutzung der öffentlichen Entwicklung. In der Developer Community findet sich das Ticket [2], das für die Implementierung dieser (nach Ansicht des Autors sehr nützlichen) Funktion sorgte.
Nicht direkt auf das Programmverhalten, mitunter aber auf die Karriere der Programme erzeugenden Entwickler:innen, wirken sich Rechtschreibfehler im Code aus. Microsoft führte schon in Version 17.5 eine Rechtschreibkorrektur ein, die in Version 17.6 Erweiterungen erfuhr. Fokus der Erweiterungen liegt dabei auf der Eliminierung von „false positives“. Gesprochene bzw. geschriebene Sprache und Programmiersprache unterscheiden sich nun mal dadurch, dass man in Programmdokumentationen oder Variablennamen mitunter Strings wie guid vorfindet.
Die neue Version von Visual Studio bringt für jede Programmiersprache spezifische Wörterbücher mit, die die häufigsten Termini Technici abzudecken versuchen. Außerdem werden einige Arten von Strings komplett ausgenommen; zu guter Letzt ist es auch möglich, hauseigene Anpassungen an der Engine durchzuführen. Weitere Informationen zu den verschiedenen von Microsoft zur Verfügung gestellten Eingriffspunkten [3] finden sich im auf dem DevBlog von Visual Studio.
Microsoft experimentiert seit einiger Zeit mit der Starterfahrung. Problematisch an Visual Studio 2019 war, dass das modulare Startfenster nicht alle Elemente der IDE vollständig einblendete. In der Praxis galt leider, dass Entwickler:innen den (zugegebenermaßen etwas kleinen) Link zum Start der IDE ohne Projekt nur allzu oft nicht fanden. Visual Studio 17.6 Preview 2 löst dieses Problem durch den in Abbildung 3 gezeigten Tab. Er hat weiterhin den aus Visual Studio 2019 bekannten Aufbau, erscheint nun aber als Tab in der vollen integrierten Entwicklungsumgebung.
Abb. 3: Die neue Out-of-the-Box-Experience startet in der vollen IDE
Eine weitere Komfortsteigerung betrifft den Remote File Explorer in Abbildung 4. Er steht nun auch dann zur Verfügung, wenn sie unixoide Ziele ansprechen. Da man sich beim Zugriff auf das Dateisystem so den Umweg auf SCP oder den Ausbau der SD-Karte erspart, ist das eine Funktion, die in der Praxis Zeit und Geld sparen dürfte.
Abb. 4: Der Remote File Explorer: jetzt auch für Unix (Bildquelle: Microsoft)
Der Embedded-Bereich war traditionell Eclipse-basierten IDEs vorbehalten: ARM pflegte mit Keil sogar eine komplette Eigenentwicklung. Auf der Embedded World dieses Jahres machte Microsoft immense Fortschritte (sowohl auf Kosten von Eclipse als auch auf Kosten von Embeetle). Mehrere Halbleiterhersteller kündigten an, fortan auch Visual-Studio-Code-basierte Varianten ihrer Mikrocontroller-Toolchains anzubieten.
STMicroelectronics (Kasten: „Mehr zu STM“) geht einen Schritt weiter und bietet neben CUBE und Visual Studio Code auch Unterstützung für die vollwertige STM32-Entwicklung in Visual Studio 2022 an. Zur Nutzung dieser Integration – wir werden sie in einem Folgeartikel vorstellen – ist das Vorhandensein der Versionen STM32CubeIDE 1.9.0 und STM32CubeMX 6.5.0 erforderlich. In der Dokumentation weist Microsoft an mehrerlei Stelle darauf hin, dass es zu schwer nachvollziehbaren Fehlern führen kann, wenn Nutzer:innen parallel andere Versionen der STM Toolchain installiert haben.
Schon aus Platzgründen kann dieser Visual-Studio-Update-Artikel nicht im Detail auf die neuen Funktionen eingehen. Ebenfalls im DevBlog [4] findet sich allerdings eine lesenswerte Zusammenfassung.
Wollen Entwickler:innen ihre in Cube IDE angelegten Projekte laden, kommt die in Abbildung 5 gezeigte Menüoption zum Einsatz. Im Hintergrund arbeitet dabei eine auf CMake basierende Toolchain. Angemerkt sei in diesem Zusammenhang, dass die Bearbeitung der für den Codegenerator notwendigen .ioc-Steuerungsdateien weiterhin in Cube erfolgt. Wer die Datei doppelt anklickt, lädt Cube und führt dort die notwendigen Änderungen an den Konfigurationen der Peripheriegeräte durch.
Abb. 5: Diese Option lädt STM-Projekte (Bildquelle: Microsoft)
Außerdem gilt, dass Microsoft (längerfristig) Unterstützung für das Debuggen der (immer komplizierter werdenden) CMake-Build-Steuerungsdateien vorsieht. Zum Zeitpunkt der Drucklegung dieses Artikels gilt das allerdings nur für die in Visual Studio eingebaute Version von CMake. Aktuell erscheint beim Auftreten von CMake-Kompilationsfehlern das in Abbildung 6 gezeigte Banner. Der Build-System-Debugger bietet dann alle üblichen Features. Es ist auch möglich, zur Analyse von Zuständen Breakpoints zu setzen.
Abb. 6: Microsoft lädt zur unterstützten Fehlersuche im Build-System ein
Nutzer der Unreal Engine können Fehlermeldungen, die das Headeranalysetool generiert, direkt in Visual Studio ansehen. Wichtig ist dafür lediglich, dass die Option IDE support for Unreal Engine im Installer aktiviert ist. Außerdem gibt es über die Option View | Other Windows | UE Log die Möglichkeit, das Event-Log direkt in Visual Studio zu laden. Diese Funktion verhält sich so, wie man es als Entwickler:in von Android Logcat gewohnt ist.
Möchten Sie tiefer in die Welt von Visual Studio einsteigen, so empfiehlt sich die Nutzung des bereitstehenden Entwicklerblogs [5]. Bei der praktischen Nutzung der Preview-Versionen ist es außerdem wichtig, die Liste mit Open Issues zu verfolgen [6]. Microsoft führt die Entwicklung von Visual Studio ja seit einiger Zeit in der Öffentlichkeit durch und informiert auf dieser Webseite detailliert über verschiedene bekannte Probleme in der integrierten Entwicklungsumgebung.
© Visual Generation/shutterstock.com
Seit Microsofts Entscheidung, Visual Studio unter Continuous Delivery weiterzuentwickeln, bekommen Nutzer:innen der IDE regelmäßig kleine Updates mit diversen Helferlein. Hier ein Überblick aktueller Neuerungen.
© j.chizhe/shutterstock.com, © S&S Media GmbH
Dieses Jahr hat die integrierte Entwicklungsumgebung Visual Studio ihren 25. Geburtstag gefeiert. Wir haben zu diesem Anlass einen etwas anderen Rückblick auf die vergangenen Jahre gestaltet und einige unserer Expert:innen zu ihren persönlichen Erinnerungen, High- und Lowlights in Bezug auf Microsofts Visual Studio befragt. Die Antworten können Sie im Folgenden lesen.
Mit Visual Studio 17.6 arbeitet Microsoft weiter daran, Visual Studio in den Mittelpunkt der Entwicklerarbeit zu stellen. Der Gutteil der Änderungen bringt direkte Quality-of-Life-Verbesserungen, ohne Änderungskosten zu verursachen – in diesem Sinne: gut Code!
[1] https://github.com/tgjones/HlslTools
[2] https://developercommunity.visualstudio.com/t/allow-creation-of-breakpoint-groups/918985
[3] https://devblogs.microsoft.com/visualstudio/improving-the-spell-checker/
[4] https://devblogs.microsoft.com/cppblog/importing-st-projects-into-visual-studio/