Vor etwas über zwei Jahren startete ich für mich persönlich ein Experiment. Ich habe mir einen MacBook Pro mit dem zu der Zeit neuen M1 Prozessor gekauft. Für mich war das tatsächlich ein großer Schritt, da ich meinen Fokus auf der .NET Plattform von Microsoft habe und damit seit über 15 Jahren bis auf wenige Linux-Ausflüge primär auf Windows unterwegs war. Der neue M1 Prozessor und dessen Balance aus Leistung und Akkulaufzeit war dabei ein Auslöser der Entscheidung für das Experiment. Es kamen aber auch andere Faktoren dazu. Immer häufiger bin ich etwa bei Kunden und im Bekanntenkreis auf macOS Benutzer gestoßen. Die Zeit war also mehr als reif, mich selbst als Entwickler mit der Plattform zu beschäftigen. Über meine Erfahrungen, Ärgernisse und warum es für mich Stand heute eine gute Entscheidung war, erfährst du mehr in diesem Artikel.
Allgemeines
Yaml Dateien mit C# parsen
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.
.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.
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.
RK 2048 – Ein Spiel vollständig als Universal App entwickelt
Ein völlig verregneter Sonntag, nichts wirklich vor, was kommt dabei raus? Richtig, ein kleines Spiel. Letzten Sonntag habe ich die frisch auf Windows Phone portierte 3D-Engine verwendet, um einen kleinen 2048 Klon zu bauen. Der Screenshot zeigt das Ergebnis. Sieht an sich relativ gut aus und funktioniert auch überraschend gut. Ein paar Bugs gibt es sicherlich noch, ein paar Optimierungen für das Phone sind noch nötig, viel mehr als einen weiteren solchen verregneten Tag braucht es aber höchstwahrscheinlich nicht mehr. Das Besondere an dem Thema von der technischen Seite ist, dass es das neue Template für Universal Apps verwendet. Der gleiche Code läuft also für Windows 8.1 und für Windows Phone 8.1 – ganz ohne Compiler-Flags oder dergleichen.