Modernized Runtime
Version 16 and earlier were based on the .NET framework, which Microsoft has stopped evolving (and some versions will be end-of-life this decade). We have migrated to the modern .NET stack (currently .NET 10) which is Microsoft’s latest and greatest. This has allowed us to modernize many areas of the product, and will allow us to adopt new features which are not being developed for the old .NET framework.
Modern .NET is also cross-platform, which has allowed us to add support for Linux. This has enabled us to include support for container technologies such as Docker and Kubernetes.
This move is a breaking change, and will require changes to existing device plugins built for Connexion version 16 and earlier. We will be providing detailed guides as well as LLM playbooks to ease the transition from v16-based plugins to version 26.
What changed
Services (Connexion, Gateway, Remote Agent, etc) target
.NET 10and are cross-platform.User interface applications, such as the Connexion and Gateway management applications, tray applications, configuration wizards, etc., target
net10.0-windows, and remain Windows only.Connexion is now x64-only. Legacy x86 execution groups are not part of the v26 runtime model.
Device plugins have moved from a single project model which includes both UI and runtime to a 2-project model - runtime and UI.
What this enables
Capability | Why it matters |
|---|---|
Linux support | The server-side runtimes can now run outside Windows. This in turn allows us to target platforms like Kubernetes to allow dynamic scaling. |
Cost Efficacy | With support for Linux and Postgres, Connexion can be deployed on platforms which have lower initial and operating costs. Additional support for dynamic scaling allows you to scale Connexion clusters up/down based on demand. |
Modern hosting | v26 can use current .NET hosting patterns, including Windows Services, systemd, ASP.NET Core hosting, gRPC services, health checks, and modern configuration providers. |
Performance headroom | .NET 10 gives Connexion current JIT, GC, tiered compilation, async streams, channels, pipelines, and newer memory APIs. This is the foundation for lower-allocation message paths, streaming transports, and improved startup and steady-state behavior. |
Simpler dependency graph | Many .NET Framework-era dependencies and vendored libraries were removed or replaced with actively maintained packages that support modern .NET. |
Cleaner future feature work | New platform work can assume a modern runtime instead of carrying .NET Framework compatibility branches. Features such as gRPC streaming, OpenTelemetry, MCP tooling, containerization, and cross-platform service hosting all depend on this foundation. |
What changed for deployment
Windows deployment continues through the Windows service and desktop tooling model (Installers & Wizards).
Linux deployment is server-focused. Linux binaries can be copied (we haven’t added APT support yet) and then CLI-based configuration wizards run. These wizards are CLI equivalents to the Windows wizards (and can also be run on windows).
Linux is not a replacement for the Windows desktop clients. Those remain Windows-only.
Self-contained Linux artifacts and container images can be used for container deployments.
What changed for custom plugins and custom code
Custom plugins built for v16 / .NET Framework must be ported to v26 / .NET 10.
Plugin projects should move to SDK-style projects and target
net10.0, ornet10.0-windowswhen they include WPF UI.The .NET framework large monolithic Connexion libraries have been refactored into more appropriate smaller projects/assemblies. Most of the non-core namespaces have changed.
Support context
Microsoft lists .NET 10 as a long-term support release, supported for three years.
Modern .NET has an annual release cadence, with even-numbered releases on the long-term support track.
.NET Framework 4.8.1 remains supported as a Windows component, but it keeps Connexion tied to Windows and the older framework ecosystem.