GitHub
github.com/RolandKoenig/MessageCommunicator

Das Projekt
Dieses Projekt ist aus der Idee entstanden, ein Set an Klassen für einen einfachen TCP/IP basierten Nachrichtenaustausch mit den neusten Mitteln aus .Net Core zu machen. An sich nichts Weltbewegendes, es war von Anfang an mehr als Übung gedacht. Mit der Zeit ist das Projekt aber schon etwas gewachsen und eine Cross-Plattform fähige GUI drum herum entstanden. Für den einen oder anderen ist es dadurch sicher ein gutes Testwerkzeug.
Die Konkrete Funktion: In meinem Umfeld habe ich oft damit zu tun, dass mittels einfacher Nachrichten über TCP/IP kommuniziert wird. Die Erkennung von Nachrichten im TCP/IP Datenstrom erfolgt dabei mit Regeln wie „Endekennzeichen“, „Feste Länge“ oder „Längenangabe in der Nachricht“. Der Message Communicator macht genau das, man kann eine oder mehrere Verbindungen definieren und je Verbindung das Nachrichtenformat festlegen. Anschließend kann man bei erfolgreichem Verbindungsaufbau mit der Gegenstelle „chatten“. In Summe ist es als Testprogramm gedacht. Bei den Verbindungen wird folgende Funktionalität unterstützt:

1. Unterstützung Passiv/Aktiv: Warten auf Verbindungsanfrage von außen auf bestimmten Port / Aufbau einer Verbindung zu einer fremden IP-Adresse und Port
2. Unterstützung TCP oder UDP: Modus kann einfach in der Konfiguration umgestellt werden.
3. Einzelne Verbindung: Trifft eine neue Verbindungsanfrage an einem Port ein, so wird die vorherige als ungültig erklärt (gilt für passiven Modus)
4. Timeouts: Trifft über eine gewisse Zeitspanne keine Nachricht von der Gegenseite ein, so wird die Verbindung automatisch abgebaut und ein neuer Verbindungsaufbau versucht
5. Flexible Nachrichtenerkennung: Die Logik zur Erkennung einer Nachricht kann flexibel konfiguriert werden. Z. B. Erkennung einer Nachricht auf Basis eines Ende-Kennzeichens oder einer festen Länge.
6. Automatischer Reconnect: Sobald ein Verbindungsprofil gestartet wurde, kümmert es sich automatisch um den Verbindungsaufbau und um ggf. notwendige reconnects.

Neben der GUI steht die Funktionalität dahinter aber auch in einer Library per Nuget zur Verfügung. In der Readme auf Github sind entsprechend zwei kurze Beispiele.

Technologie
Unabhängig von der reinen Funktion ist das Projekt sicher auch von der Technologie her interessant. Die GUI basiert auf Avalonia und läuft damit auf Windows, Linux und macOS.Wer es nicht kennt: Avalonia ist ein OpenSource-Framework und ähnelt sehr stark WPF. Während der Arbeit an diesem Projekt war ich von der Stabilität und dem Reifegrad des Frameworks sehr überrascht – abgesehen von einigen kleinen Ecken und Kanten natürlich. Als Runtime verwende ich aktuell .Net Core 5.

Download
Das Programm kann man sich direkt von GitHub bei Releases runterladen oder auch über den Windows Store installieren (?? App „Message Communicator“).

Nächste Schritte
Ich selbst habe momentan das meiste eingebaut, was ich brauche. Gerne könnt ihr euch das Projekt bei Interesse anschauen und Rückmeldung geben.

Code sieht schon ganz gut aus; aber einfach aus Feedback-Gründen: Dein Namespace Handling ist mir unklar.
Verstehe die ganzen Verzeichnisse mit Underlindes nicht; steht alles etwas im Gegensatz, wie man Namespaces designed / desginen sollte - zumindest wenn man die C# Guidelines und die "normalen" Open Source Umsetzungen so sieht. Etwas schwer sich da zurecht zu finden als Außenstehender.

Zudem, weil Du es ja als Übung gesehen hast: Serialisierung ist derzeit ein Thema, bei dem immer öfter Source Code Generators sinnvoll eingesetzt werden können.
Beispiel: https://github.com/RudolfKurka/StructPacker

Danke für dein Feedback

Das mit den Namespaces ist tatsächlich noch eine sehr alte und eigenwillige Angewohnheit, bei der es auch mal an der Zeit wird, sie an den Nagel zu hängen. Die Grundregel ist eigentlich ganz einfach, Ordner mit _ vorne dran zählen nicht als eigener Namespace.
Mal gucken, vielleicht ändere ich das direkt mal in der nächsten Zeit. Ist ja grundsätzlich nicht so wild.

Beim Thema SourceGenerators bin ich ganz bei dir.
Ich verfolge das Thema auch seit diesem Post im .Net Blog und finde es sehr spannend. Ich sehe dafür auch einige Anwendungsfälle, ganz unabhängig von der Serialisierung.

Bei der Library MessageCommunicator ging es mir zunächst darum, den Code so zu schreiben, damit möglichst wenig allokiert und möglichst selten mit locks gearbeitet wird. Das Thema Cross-Plattform Testtool (mit GUI) kam dann eher so nebenbei rein. Insbesondere deswegen, weil ich von Avalonia sehr positiv überrascht war und weil ich tatsächlich so ein Tool immer wieder mal brauche. Es steckt aber viel Spielerei drin, was gar nicht so dringend notwendig ist. Zum Beispiel verschiedene Themes, automatischer Wechsel zwischen Hell und Dunkel auf Windows, überall Eingabevalidierung, integrierte Markdown-Dokumentation, etc.
Für mich war das in Summe schon sehr spannend, da ich in den letzten 13 Jahren primär auf Windows unterwegs war.

Ich habe gesehen, dass Du als Abhängigkeit das NuGet StringFormatter verwendest. Überlege mal diese Implementierung durch den Standard zu ersetzen. In .NET Core 5 - und auch schon davor - wurde sehr viel an der Performance und dem Speicherbedarf im Framework optimiert. Ich wäre der Meinung, dass es einen Blog-Eintrag vom Microsoft hierzu gäbe, hab ich nur nicht gefunden. Nur den hier: Performance Improvements in .NET Core 5