# OPCFoundation/UA-.NETStandard: the reference OPC UA stack for .NET, now on 2.0

> The OPC Foundation's own C# implementation of OPC UA ships client, server, PubSub, GDS and companion-spec libraries. Version 2.0 on master brings breaking API changes and an analyzer-assisted migration path, while the 1.x line stays on master378.

**OPCFoundation/UA-.NETStandard** — OPC Unified Architecture .NET Standard

- Repository: https://github.com/OPCFoundation/UA-.NETStandard
- Stars: 2,393 · Forks: 1,058
- Language: C#
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/opcfoundation-ua-netstandard

## Who the OPC UA .NET Standard stack is actually for

OPC UA is an industrial interoperability standard, and this repository is the OPC Foundation's own reference implementation of it for .NET. The README describes it as "a certified, cross-platform stack with client, server, PubSub, GDS, complex types, and source-generated tooling" and lists industrial control, manufacturing, energy and IoT as the areas where it is used in production. That framing matters: this is not a general-purpose networking library that happens to speak an industrial protocol. It is the stack you reach for when a machine, a line controller or a SCADA integration has to expose or consume an OPC UA address space and pass a compliance test.

The audience is therefore narrow and specific. You are writing C# and you need a server that a third-party OPC UA client can browse, or a client that can talk to a PLC, a historian or another vendor's endpoint. The companion-spec coverage listed in the README (Part 9 Alarms and Conditions, Part 11 Historical Access, Part 13 Aggregates, Part 16 State Machines, Part 18 Role Management, Part 100 Device Integration, plus domain models for ISA-95, robotics and the Asset Administration Shell) tells you the project expects you to implement a real information model, not just move a few values over TCP. If your requirement is simply publishing sensor readings to a cloud broker, the protocol weight here is not earning its keep.

## How the stack is put together: libraries, transports and the 1.x/2.0 split

The repository is a solution file, UA.slnx, over a set of libraries split by role: Core, Client, Server, PubSub, GDS, LDS, Complex Types, Device Integration and Positioning. Transports named in the README are UA-TCP and HTTPS. Target frameworks are .NET 10, .NET 9, .NET 8 (LTS), .NET Framework 4.8 and .NET Standard 2.1, and the README states the assemblies are Native-AOT friendly, which is a meaningful constraint on how much reflection the stack can do at runtime.

The branch layout is the part most readers will trip over. Current master is version 2.0. The supported 1.x line lives on the master378 branch, last released as 1.5.378, and the README says master378 "continues to receive security and critical-bug fixes for the 1.x line" while all new feature work happens on master. So the question "which version am I on" has a branch answer, not just a version-number answer. The 2.0 line also introduces breaking API changes, which the project acknowledges by shipping a prescriptive migration guide plus per-area migration documentation under docs/migrate/2.0.x/.

A second structural detail worth internalising is the release channel. Preview builds from successful master builds go only to the GitHub Packages NuGet feed. nuget.org receives a version only through a manually approved promotion from a release/<major>.<minor> branch. That means the packages you can restore from nuget.org and the packages that exist on master are not the same set at any given moment.

## Installing the stack and running a first build

The README states you need the .NET 10 SDK to build the repository. From the repository root, the two commands it gives are a restore and a build against the solution file:

```bash
dotnet restore UA.slnx
dotnet build UA.slnx
```

If the restore fails because it cannot find a package, check NuGet.config in the repository root before assuming the package does not exist; the preview feed configuration lives in the repository's own NuGet setup rather than in your global config.

For application code, the README points at the OPCFoundation.NetStandard prefix on nuget.org. The meta package pulls in everything, or you reference individual packages:

```bash
# everything
dotnet add package OPCFoundation.NetStandard.Opc.Ua

# clients only
dotnet add package OPCFoundation.NetStandard.Opc.Ua.Client

# servers only
dotnet add package OPCFoundation.NetStandard.Opc.Ua.Server
```

For the 2.0 preview line, the README says to enable prerelease packages and float with 2.0.0-preview.* until 2.0.0 is released. Note the caveat it adds: the XRegistry, WoT Connectivity, Vision, Robotics, Redundancy, Positioning, OpenUSD, ISA95, AI and DI package families stay preview packages even when the root version is promoted to a stable version, and keep their own -preview.N versions.

A first real use is easier to reach through the samples than through the libraries directly. The repository ships platform-independent sample applications under samples/, including FluentApi, MinimalApi, Quickstarts.Servers, Reference and UAReferenceServer.ctt.xml, and the README points at docs/samples.md for the index. Start the reference server sample, then point a client sample at it. For anything beyond that, the companion repository OPCFoundation/UA-.NETStandard-Samples is where the README says platform-specific examples live.

## The 2.0 migration burden is real, and the tooling only covers part of it

The honest limitation of this project right now is the upgrade. The README states plainly that 2.0 "introduces breaking API changes". The mitigation is a NuGet analyzer, OPCFoundation.NetStandard.Opc.Ua.MigrationAnalyzer, which the README says provides 26 analyzer rules through UA0030 with one-click code fixes, explicitly excluding UA0013, UA0016, UA0017 and the shim-only UA0029. Twenty-six rules is a large surface, and the exclusions mean four of the categories are not automated. The README's own wording for what is left after the analyzer runs is "the small residual manual patterns", which is the project's characterisation, not a measurement you can rely on for your codebase.

There is a second path: an agent skill named opcua-v20-migration under .agents/skills/, described as walking Copilot, Claude or any coding agent through installing the NuGet, running dotnet format analyzers to apply auto-fixes, and loading the right sub-document per symptom. Copilot CLI discovers the skill automatically inside a clone; for other repositories the README gives an explicit plugin install:

```bash
copilot plugin marketplace add OPCFoundation/UA-.NETStandard
copilot plugin install opcua-v20-migration@opcua-dotnet
```

Delegating a migration to a coding agent is a choice you should make deliberately. The analyzer rules are deterministic and reviewable in a diff. The agent path is not, and the README does not describe a verification step beyond the sub-documents the skill loads.

Two other boundaries are worth stating. The stack is C#; if your service is Python or Node.js, this repository is not the answer and the README does not claim otherwise. And the repository's licence field is NOASSERTION with a LICENSE.txt at the root, so the licence terms are not summarised in the README and you should read LICENSE.txt directly rather than inferring terms from the OPC Foundation's name.

## What you would use instead, and where the difference bites

The most direct alternative is to stay on the 1.x line. That is not a different project, but it is a genuinely different engineering decision: master378 receives security and critical-bug fixes while master takes the feature work, so you trade new companion-spec coverage and the 2.0 developer surface for API stability. The README's own closing advice to 1.x users is to stay on master378 if they are not ready to upgrade, which is an unusually direct statement from a project that also wants you on the new line.

Outside this repository, the meaningful alternative is a non-.NET OPC UA stack, and the practical reason to choose one is language, not features. If the surrounding system is Java, Python or C, the cost of bridging into .NET usually exceeds whatever the reference implementation buys you in compliance coverage. The trade is that you lose the OPC Foundation's certification story: the README states the reference server has been certified through an OPC Foundation Certification Test Lab and is continuously verified against the Compliance Test Tool, and that is a property of this implementation rather than of the protocol in general.

A third option, for readers whose actual requirement is MQTT-style publish and subscribe rather than a browsable address space, is to not use OPC UA at all. This stack does include PubSub, so it can be the right tool for broker-mediated telemetry, but if nobody in the deployment needs the information model, the certification or the companion specs, you are paying for machinery you will not exercise.

## Maintenance cadence, release channels and what to watch

The repository is not archived and the last push was on 2026-09-28, the same day as this writing, so there is no maintenance concern to report. The recent release list shows both lines moving: 1.5.378.176 (OPC UA 1.05 Maintenance Update) on 2026-09-11 and 1.5.378.156 on 2026-07-10 for the 1.x line, and 2.0.0-preview.2 (V2.0 Preview 2) on 2026-08-24 for the 2.0 line. That pattern matches the branch description: maintenance on 1.x, feature work on 2.0.

The upgrade cost you should budget for is not the package version bump. It is the analyzer run, the four excluded rule categories, and whatever the README calls the residual manual patterns. The repository gives you three concrete levers: the MigrationAnalyzer package, dotnet format analyzers, and the migration guide with its per-area sub-documents. Use them in that order and treat the analyzer output as the estimate, not the guide's prose.

On licensing, the only fact available here is that the repository's licence is recorded as NOASSERTION and that a LICENSE.txt sits at the repository root. The README does not restate the terms. If you are shipping this inside a product, read LICENSE.txt and, where the OPC Foundation's certification marks are involved, check the certification requirements separately from the code licence. Nothing in the README addresses either point.

## Conclusion

Adopt UA-.NETStandard if you need a certified, cross-platform OPC UA client or server in C# and can build against .NET 10 SDK, or stay on the master378 branch if you are not ready for the 2.0 breaking changes. Do not pick it for a Python or JavaScript service; the repository is C# only and the README points elsewhere for other languages. Before committing, verify that the exact NuGet package you need is on nuget.org rather than the GitHub Packages feed, and run the MigrationAnalyzer against a copy of your project to see how many of the 26 rules fire.

## FAQ

### What is the OPC UA standard, and what does UA-.NETStandard implement of it?

OPC UA is the industrial interoperability standard this repository implements for .NET. The README describes the stack as covering Core, Client, Server, PubSub, GDS, LDS, Complex Types, Device Integration and Positioning libraries, with UA-TCP and HTTPS transports, plus companion specifications from Part 9 through Parts 210 and 211.

### What is the difference between OPC UA and MQTT, and does UA-.NETStandard cover both?

The repository implements OPC UA, including its PubSub model, but it does not implement MQTT. The README lists UA-TCP and HTTPS as the transports, so a deployment that needs an MQTT broker is outside what this stack provides.

### Can UA-.NETStandard be used from Python?

No. The repository's primary language is C# and it builds on .NET target frameworks. The README does not describe Python bindings, so a Python service would need a separate OPC UA stack.

## Sources

- [Issues](https://github.com/OPCFoundation/UA-.NETStandard/issues)
- [OPCFoundation/UA-.NETStandard on GitHub](https://github.com/OPCFoundation/UA-.NETStandard)
- [README](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/README.md)
- [Releases](https://github.com/OPCFoundation/UA-.NETStandard/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opcfoundation-ua-netstandard