Es gibt eine lange Liste von verbreiteten Markup-Formaten. Xml und Json sind dabei den allermeisten Entwicklern ein Begriff. Auch Yaml ist ein Format, welches nicht zuletzt durch den Einsatz bei Kubernetes oder anderen bekannten Applikationen eine größere Verbreitung genießt. Yaml wirkt auf den ersten Blick wie ein “Json ohne Klammern”. Das habe ich selbst tatsächlich auch lange so angenommen. Beschäftigt man sich etwas tiefer im Detail mit Yaml, so wird man aber schnell eines Besseren belehrt. Yaml bietet mehrere Features und hat etwa bei der Ermittlung der Datentypen ein mehr oder weniger komplexes Regelwerk. Aber warum überhaupt Yaml, wenn man doch auch Json einsetzen könnte? Yaml-Dateien könnten leichter durch einen Menschen geschrieben und gelesen werden. Aus diesem Grund wird es gerne für Konfigurationsdateien verwendet – so wie etwa bei Kubernetes. Somit kann es auch für C# Entwickler sinnvoll sein, anstelle von Json oder Xml eben Yaml für Konfigurationsdateien zu verwenden. Aus diesem Grund möchte ich mich in diesem Artikel mit dem Parsen von Yaml Dateien mit C# beschäftigen.
Allgemeines
.Net 5 App Trimming am Beispiel MessageCommunicator
Das Tool MessageCommunicator (Siehe [1]) ist so konzipiert, dass es möglichst portabel sein soll. Idealerweise als schlichte Exe-Datei (bzw. ausführbare Datei auf Linux oder macOS). Mit dem Parameter PublishSingleFile ist das seit .Net Core 3.0 grundsätzlich möglich, einziges Problem ist lediglich die Größe der ausführbaren Datei. Man kann es sich aussuchen: Entweder man verteilt eine kleine Datei, setzt aber dann ein installiertes .Net am Zielsystem voraus, oder man hat eine größere Datei und bringt die Abhängigkeiten aus .Net direkt mit. Ich persönlich bevorzuge letzteres – es ist schlicht für alle Beteiligten einfacher, wenn eine Applikation möglichst wenig Voraussetzungen an das Zielsystem stellt. Mit den neuesten Funktionen rund um das App Trimming [2] kann an der Größe der zu verteilenden Dateien schrauben. In diesem Artikel möchte ich dazu meine Erfahrungen aus dem Projekt MessageCommunicator weitergeben.
Talks auf der ADC 2020 in München
Die Konferenz ADC 2020 fand trotz Corona statt und hat eine gute Plattform für Vorträge und Gespräche zu aktuellen Themen im .Net Umfeld geboten. Ich selbst war mit je einem Vortrag zum Thema WinUI und ASP.Net Core Blazor mit vor Ort in München. Die Coding-Beispiele beider Vorträge liegen entsprechend auf Github unter [1] und [2].
Gemeinsame Icon-Bibliothek in größeren Desktop-Apps
Je umfangreicher Desktop-Apps werden, desto größer wird auch ein Problem, welches zumeist zu Beginn der Entwicklung unterschätzt wird: Wo werden Icons abgelegt, welche von verschiedenen Programmteilen verwendet werden? Viele verschiedene Programmteile und Module (und wie sie auch immer genannt werden…), bei denen jeweils lokal Icons abgelegt werden, können nach einigen Jahren stetiger Entwicklung für Chaos sorgen. Bei meinen Projekten verstärkt sich das Problem zusätzlich aufgrund der Tatsache, dass sich ältere Windows.Forms- und neuere WPF-Komponenten mischen.
Worklog RK Rocket #3: Sound per XAudio2
Mit Audio-Wiedergabe per DirectX habe ich mit bis dato nicht wirklich beschäftigt – schlicht noch nie gebraucht. Bei einem Spiel wie RK Rocket sieht das aber anders aus, denn wenn der Spieler feuert, ein Ziel trifft oder getroffen wird, sollte auch ein entsprechender Ton aus den Lautsprechern kommen. Neben der technischen Umsetzung gibt es für mich an dieser Stelle das Problem, den richtigen Content (=Sound-Dateien) zu bekommen, die auch zur Lizenz des Quellcodes von RK Rocket passen (=LGPL). Am Ende war beides glücklicherweise deutlich einfacher, als gedacht.
Worklog RK Rocket #2: Maus, Tastatur, Gamepad
Für RK Rocket habe ich damit begonnen, das Eingabe-System von Seeing# vernünftig auszuprogrammieren. Eingabesystem bedeutet in diesem Fall, dass Seeing# im Hintergrund automatisch die Status-Werte der angebundenen Eingabegeräte unabhängig von der aktuellen Oberflächen-Technologie (WPF, Win.Forms, WinRT) abfragt, in ein gemeinsames Format bring und dann an die aktuellen Spiele-Komponenten weiterleitet. Das klingt erst einmal einfach, ist aber nicht ganz zu unterschätzen. Probleme kommen etwa daher, weil auch jede Oberflächen-Technologie in Windows seine API ein bisschen anders bereitstellt. Weiterhin macht die Architektur von Seeing# selbst die Aufgabe nicht einfacher, da konsequent auf Multithreading, Multi-View und theoretisch auch mehrere Szenen gesetzt wird.
Worklog RK Rocket #1: Basics
Aktuell arbeite ich relativ viel an der Integration von Direct2D in Seeing#. Diese API ist für mich der interessanteste Weg, 2D-Funktionen in eine auf Direct3D basierende 3D-Engine zu bringen. Man arbeitet mit aus anderen APIs bekannten einfachen Funktionen wie DrawRect, DrawLine oder DrawBitmap, ist aber vollständig hardwarebeschleunigt unterwegs und man kann direkt auf Texturen zeichnen, welche auf ein 3D-Objekt geklatscht werden. Oder schlich in den Vorder- bzw. Hintergrund der 3D-Ansicht. RK Rocket ist ein kleines Spiel, anhand dem ich die 2D-Funktionen in Seeing# integriere und direkt teste. Es ist ein einfaches kleines Game, inspiriert vom Rockout-Beispiel der Programmiersprache BlitzMax [1]. Es wird als UWP App erstellt und ist somit auf möglichst allen Windows 10 Geräten lauffähig.
Um was geht es beim Testen?
Neulich stand am .Net Usergroup-Treffen in Regensburg das automatisierte Testen auf der Agenda [1]. Grundsätzlich ein wichtiges Thema, nicht nur für mich, sondern auch für viele andere Softwareentwickler – alleine die hohe Teilnehmerzahl macht dies deutlich. An dieser Stelle direkt ein Dank an den Sprecher Kenny Pflug, er hat das Thema gut dargestellt – auch wenn es die eine oder andere Kritik an dem Beispielprogramm gab ;). Bei dem Vortrag konnte ich einige Dinge dazulernen, beispielsweise nennt sich das, was ich normalerweise als “Testdriven Development” in der Arbeit vorantreibe, in Wirklichkeit “Behavior Driven Development”. Naja.. ich mache mir halt nicht viel aus Schlagworten 😉
RK2048 – Universal-App fast fertig
RK2048 ist mein erstes “Abenteuer” eine App mit weitgehend gleichem Coding auf mehreren Plattformen zu entwickeln und zu veröffentlichen. Genau genommen handelt es sich um (fast alle) aktuellen Windows-Plattformen von Windows Phone (8.1) über Windows RT bzw. Windows Store Apps bis Windows Desktop (Wpf). Es ist überraschend, wie gut das mittlerweile zwischen Phone und Tablet funktioniert, einzig WPF ist bei den Standard-Projekttemplates noch etwas außen vor. Im Windows Store ist die erste Version schon veröffentlicht, Windows Phone folgt (hoffentlich) relativ bald. Auch ein Setup für die Desktop-Version ist bereits verfügbar.
MSTest, oder wie ich es verwende
UnitTests oder Ansätze der testgetriebenen Entwicklung werden aktuell häufig bei Usergroups oder Fachkonferenzen angesprochen. Erst diese Woche war ich auf einem Usergroup-Treffen in Nürnberg genau zu diesem Thema. Ich persönlich beschäftige mich damit schon etwas länger, habe testgetriebene Ansätze bereits mehrmals bei passenden Anwendungsfällen durchgeführt und war damit auch stets sehr zufrieden. Bei dem genannten Vortrag musste ich aber feststellen, dass sich das, was ich persönlich mit diesen Tests mache, mittlerweile schon teils deutlich von der Theorie unterscheidet. Hier in diesem Beitrag möchte ich entsprechend meine Sicht auf UnitTests und testgetriebene Ansätze im Allgemeinen beschreiben.Um ganz von vorne anzufangen: Ich verwende das in Visual Studio integrierte MSTest seit ca. 3-4 Jahren, vorher habe ich keinen einzigen automatisierten Test geschrieben. Ausgelöst wurde das ganze schlicht durch den Wunsch, gewisse Logiken nicht immer manuell neu testen zu müssen. Zudem habe ich an mir und auch bei Bekannten festgestellt, dass man sich gerne Testoberflächen bastelt, um damit neu entwickelte Logik-Bausteine zu testen. Diese Testoberflächen verschwinden aber gerne im Laufe der Entwicklung wieder oder werden aus Gründen der schlechten Usability einfach nicht mehr zum Nachtesten verwendet. UnitTests waren bzw. sind meiner Ansicht nach ein besserer Weg um genau das Gleiche zu erreichen. Vorteil: Die Testlogik bleibt im Projekt bestehen und kann jederzeit ausgeführt oder gar direkt in den Build-Prozess integriert werden.