Da freut man sich, dass die NET-Familie inzwischen auf vielen Betriebssystemen zuhause ist und man realtiv einfach Programme schreiben kann, die auf Windows, Linux-x86-64, Linux-arm64, Linux-armx86 als auch MacOS laufen und dann so etwas: Ich habe ein kleines Programm für meine PV-Anlage geschrieben, dass die bereitgestellten Daten periodisch ausliest und einem MQTT-Broker überhilft. Dieser wiederum speist mein HomeAssistant System zur Automatisierung und Visualisierung diverser Prozesse. Das ganze wurde unter NET 8.0 realisiert.
In der Entwicklungsumgebung Visual Studio 2022 unter Windows 10 lief das ganze hervorragend. Auch im Standalone-Modus ohne die Entwicklungsumgebung gab es keine Grund zur Beanstandung. Mein Produktionsserver jedoch läuft unter Linux-x64. Zwar lies sich das Programm unter Linux anstandslos starten, allerdings wurden die Werte im Broker nur dreimal "pünktlich" aktualisiert. Von da an wurden die Aktualisierungsintervalle immer größer. Ein sinnvoller Betrieb war einfach nicht möglich. Ich habe verschiedene Timer des NET 8.0 ausprobiert und bin letztendlich beim nuget-Paket eines HighResolution-Timers hängen geblieben. Egal welcher Timer verwendet wurde, das Ergebnis war dasselbe. Ein produktiver Betrieb war unter Linux-x64 einfach nicht möglich.
Gott sei Dank stehen hier noch ein paar Raspis zur Verfügung. Der für den TV-Server dedizierte Raspi langweilt sich die meiste Zeit, also entschloss ich mich, die Aufgabe diesem Rechner überzuhelfen. Das NET 8.0-Framework war unter RaspberryOS-64 schnell installiert. Die Programmdateien waren ebenfalls schnell kopiert und der beherzte Start unter dieser Betriebssystem-Umgebung wurde getätigt. Was soll ich sagen? Das Programm läuft so, wie es geplant und unter Windows ausgeführt wird.
Leider habe ich noch nicht herausgefunden, warum die Timer unter Linux-x64 nicht korrekt arbeiten. Da ich eine Lösung erst einmal gefunden habe, suche ich vorerst nicht weiter. Nur soviel: Es scheint ein Bug im NET 8.0 und Linux-x64 zu sein.