Zum Hauptinhalt springen

.NET- und Native-Plugin-Wege

Native Wege bewusst nutzen

.NET und rohe native Plugins sind nĂĽtzlich, wenn sie zu deinem bestehenden Anwendungs-Stack passen. Sie sind 2026 nicht der schnellste Standard fĂĽr ein neues Stream Deck Plugin.

1. Natives Plugin-Modell​

Elgato dokumentiert eine WebSocket-API für native Konsolenanwendungen. Stream Deck startet den Plugin-Prozess und übergibt Verbindungsdetails als Kommandozeilenparameter, darunter den Port, die Plugin-UUID, das Registrierungsevent und serialisierte App-/Geräteinformationen.

Der native Prozess verbindet sich anschlieĂźend zurĂĽck zu Stream Deck und tauscht JSON-Nachrichten aus.

Das gibt dir Runtime-Freiheit, aber du musst mehr Protokolldetails selbst behandeln.

2. Elgatos Empfehlung​

Die aktuelle WebSocket-Referenz beschreibt native Plugins als fortgeschrittene Technik und empfiehlt das Node.js SDK fĂĽr die meisten Plugin-Autoren. Behandle das als Standardregel.

Nutze native Plugins, wenn die Runtime selbst Teil der Anforderung ist.

3. StreamDeckToolkit​

StreamDeckToolkit ist eine Community-.NET-Standard-Bibliothek, ein Template und ein Tooling-Set zum Bauen von Stream Deck Erweiterungen mit .NET Core.

Es ist nĂĽtzlich, wenn:

  • das Team bereits stark in C# ist,
  • das Plugin von .NET-Bibliotheken abhängt,
  • Windows-Integration zentral ist,
  • stark typisierte Modelle wertvoll sind,
  • du ein Template willst, das die tiefere Plugin-Kommunikation abstrahiert.

4. Praktische Vorbehalte​

PrĂĽfe den aktuellen Stand, bevor du ein neues Projekt startest:

  • Template-Anforderungen können hinter aktuellen Elgato-SDK-Anforderungen zurĂĽckliegen,
  • Beispiele können auf ältere SDK-Versionen zielen,
  • Marketplace-Erwartungen können sich geändert haben,
  • Property-Inspector-Verhalten erfordert weiterhin JavaScript/HTML-Koordination,
  • du bist selbst fĂĽr das Testen auf aktuellen Stream Deck App-Versionen verantwortlich.

5. C#-Action-Konzept​

In StreamDeckToolkit werden Actions als Klassen implementiert und ĂĽber UUID-Attribute zugeordnet. Die Action muss auĂźerdem in manifest.json registriert werden, und die UUIDs mĂĽssen ĂĽbereinstimmen.

Typische Konzepte:

  • Basis-Action-Klasse,
  • Einstellungsmodell,
  • Action-UUID-Attribut,
  • Manifest-Action-Eintrag,
  • Property-Inspector-Datenmapping.

Dieses Modell ist fĂĽr .NET-Entwickelnde angenehm, aber es hat mehr bewegliche Teile als das aktuelle TypeScript-Scaffold.

6. Wann C# eine starke Wahl ist​

Wähle C#, wenn:

  • dein Plugin mit einer bestehenden .NET-Desktop-App spricht,
  • du Windows-APIs oder COM-Integration brauchst,
  • dein Team bereits getestete C#-Businesslogik hat,
  • Node.js-Native-Addons schlechter wären als ein natives Plugin,
  • du zusätzliche Validierungsarbeit gegen die aktuelle Elgato-Doku akzeptierst.

7. Wann du es vermeiden solltest​

Vermeide C# fĂĽr ein neues einfaches Plugin, wenn:

  • das Plugin nur API-Aufrufe und Anzeige-Updates macht,
  • Property-Inspector-Formulare einfach sind,
  • Marketplace-Auslieferung das Ziel ist,
  • du .NET nicht ohnehin brauchst,
  • das Team mit TypeScript zurechtkommt.

8. Rohe WebSocket-Checkliste​

Wenn du ein natives Plugin von Grund auf baust, plane fĂĽr:

  • das Parsen der Startparameter,
  • das Verbinden mit dem WebSocket-Port,
  • das Senden der Registrierungsnachricht,
  • das Modellieren eingehender und ausgehender Events,
  • das Pflegen von Action-Context-Identifiern,
  • den Umgang mit Einstellungen,
  • den Umgang mit Property-Inspector-Nachrichten,
  • das Packen der nativen ausfĂĽhrbaren Datei mit dem Plugin,
  • das Testen von App-Neustarts und GeräteverbindungsabbrĂĽchen.

Dieser Weg kann für ausgereifte native Apps sauber sein. Für kleine Plugins ist er unnötige Reibung.