Skip to main content

.NET and Native Plugin Paths

Use native paths deliberately

.NET and raw native plugins are useful when they match your existing application stack. They are not the fastest default for a new Stream Deck plugin in 2026.

1. Native plugin model​

Elgato documents a WebSocket API for native console applications. Stream Deck launches the plugin process and passes connection details as command-line parameters, including the port, plugin UUID, registration event, and serialized app/device information.

The native process then connects back to Stream Deck and exchanges JSON messages.

This gives you runtime freedom, but you must handle more protocol detail yourself.

2. Elgato's recommendation​

The current WebSocket reference describes native plugins as an advanced technique and recommends the Node.js SDK for most plugin authors. Treat that as the default rule.

Use native plugins when the runtime itself is part of the requirement.

3. StreamDeckToolkit​

StreamDeckToolkit is a community .NET Standard library, template, and tooling set for building Stream Deck extensions with .NET Core.

It is useful when:

  • the team is already strong in C#,
  • the plugin depends on .NET libraries,
  • Windows integration is central,
  • strong typed models are valuable,
  • you want a template that abstracts lower-level plugin communication.

4. Practical caveats​

Check the current state before starting a new project:

  • template requirements may lag current Elgato SDK requirements,
  • examples may target older SDK versions,
  • Marketplace expectations may have changed,
  • property inspector behavior still requires JavaScript/HTML coordination,
  • you are responsible for testing on current Stream Deck app versions.

5. C# action concept​

In StreamDeckToolkit, actions are implemented as classes and associated with UUID attributes. The action must also be registered in manifest.json, and the UUIDs must match.

Typical concepts:

  • base action class,
  • settings model,
  • action UUID attribute,
  • manifest action entry,
  • property inspector data mapping.

That model is comfortable for .NET developers, but it is more moving parts than the current TypeScript scaffold.

6. When C# is a strong choice​

Choose C# when:

  • your plugin talks to an existing .NET desktop app,
  • you need Windows APIs or COM integration,
  • your team already has tested C# business logic,
  • Node.js native addons would be worse than a native plugin,
  • you accept extra validation work against current Elgato docs.

7. When to avoid it​

Avoid C# for a new simple plugin when:

  • the plugin is just API calls and display updates,
  • property inspector forms are simple,
  • Marketplace delivery is the goal,
  • you do not already need .NET,
  • the team is comfortable with TypeScript.

8. Raw WebSocket checklist​

If you build a native plugin from scratch, plan for:

  • parsing startup parameters,
  • connecting to the WebSocket port,
  • sending the registration message,
  • modeling incoming and outgoing events,
  • maintaining action context identifiers,
  • handling settings,
  • handling property inspector messages,
  • packaging the native executable with the plugin,
  • testing app restarts and device disconnects.

This path can be clean for mature native apps. It is unnecessary friction for small plugins.