Marc Schier baab5a9750 Watch datasets that appear after the PubSub application starts (#4164)
### Problem

`MetaDataPublisher` takes its per-dataset subscriptions once, from
`StartAsync`, by walking the connections that exist at that moment:

```csharp
m_registry.MetaDataChanged += OnMetaDataChanged;
m_subscribed = true;
...
SubscribeToDataSets();
```

An application that is **configured after it starts** therefore never
subscribes to anything — at start there are no writers to walk, and
nothing looks again when they arrive. The same gap applies to a dataset
added to an already-configured application.

The visible effect is that `PublishedDataSet.MetaDataChanged` is never
observed for those datasets. A source whose fields are only known once
data has flowed — one fed by a live subscription — announces its empty
metadata and never corrects it, so a consumer that relies on the
announcement to decode the payload never sees a usable one.

This is not hypothetical: it is how a host that starts with an empty
`PubSubConfigurationDataType` and calls `ReplaceConfigurationAsync`
later behaves, which is a reasonable way to drive the application when
the configuration is not known at construction time.

### Change

`SubscribeToDataSets()` now also runs on
`IPubSubApplication.ConfigurationChanged`.

Running it more than once means it has to be idempotent, so a dataset
that is already being watched is skipped. The comparison is by
**reference**, because that is the identity the handler is bound to —
two datasets can carry equal metadata and still be different sources.
The new subscription is removed again on dispose alongside the registry
handler.

The re-entrancy check is done twice under the lock: once before
attaching the handler to avoid the work, and once after, because the
handler is attached outside the lock and a concurrent configuration
change could have added the same dataset in between.

### Scope

**This does not on its own change the order in which the first
announcement and the first data message are published.** It only ensures
the announcement happens at all for datasets the publisher was never
watching. Relates to #4152, which is about that ordering; this is a
prerequisite, not a fix for it.

### Verification

- `Opc.Ua.PubSub` builds with **0 warnings, 0 errors** across all six
target frameworks (net10.0, net9.0, net8.0, netstandard2.1, net48,
net472).
- `Opc.Ua.PubSub.Tests` on net10.0: **1341 passed, 1 skipped, 0
failed**.
2026-08-03 19:48:56 +02:00
2020-05-15 19:41:55 +02:00
2021-07-26 10:06:51 +03:00

OPC UA .NET Standard Stack

Release NuGet Downloads Build Tests Coverage

🆕 This is version 2.0 of the OPC UA .NET Standard Stack (current master).

Looking for the supported 1.x release? It lives on the master378 branch (last release: 1.5.378). All new feature work happens here on master; master378 continues to receive security and critical-bug fixes for the 1.x line.

The official OPC Foundation reference implementation of OPC UA for .NET — a certified, cross-platform stack with client, server, PubSub, GDS, complex types, and source-generated tooling. Used in production across industrial control, manufacturing, energy, and IoT systems.

📦 What it is

  • A full-stack OPC UA implementation — Core / Client / Server / PubSub / GDS / LDS / Complex Types / Device Integration / Positioning libraries built on .NET, with UA-TCP and HTTPS transports.
  • Cross-platform — runs on .NET 10, .NET 9, .NET 8 (LTS), .NET Framework 4.8, and .NET Standard 2.1; ships Native-AOT-friendly assemblies.
  • Certified for compliance — the reference server has been certified through an OPC Foundation Certification Test Lab and is continuously verified against the latest Compliance Test Tool (CTT).
  • Companion-spec coverage — Part 9 (Alarms & Conditions), Part 11 (Historical Access), Part 13 (Aggregates), Part 16 (State Machines), Part 17 (Alias Names), Part 18 (Role Management), Part 20 (File Transfer), Part 100 (Device Integration), Parts 210/211 (Relative Spatial Location and Global Positioning), OPC-10030 (ISA-95 Common Model) with OPC-10031-4 Job Control V1/V2, OPC 10100-1 (WoT Connectivity), OPC 40001-1 (Industrial Automation), OPC 40010-1 (Robotics).
  • Modern developer surface — first-class Microsoft.Extensions.DependencyInjection hosting (services.AddOpcUa()), fluent server + client builders, source-generated NodeManagers and DataTypes, and an MCP server so LLMs / Copilot can drive an OPC UA client.

For the full feature breakdown see OPC UA Profiles and Facets and the What's New in 2.0 tour.

🚀 Getting started

You need the .NET 10 SDK to build the repo. From the repository root:

dotnet restore UA.slnx
dotnet build UA.slnx

For the supported target frameworks and platform notes see the Developer Guide. The official NuGet packages are published to nuget.org under the OPCFoundation.NetStandard prefix — the meta package OPCFoundation.NetStandard.Opc.Ua pulls in everything, or pick the split OPCFoundation.NetStandard.Opc.Ua.Core / .Client / .Server / .Bindings.Https packages directly. Preview builds for every successful master build are available in the Azure DevOps opcua-preview feed.

Sample applications

Each sample has its own README.md with build and run instructions.

Reference applications

PubSub samples

  • Console Reference PubSub Client — one executable with publisher, subscriber, and external (external-server adapter) modes across the supported transport profiles.

Minimal / Device-Integration samples

  • Minimal Calc Server — minimal server built on the source-generated NodeManager pipeline (Calc model).
  • Minimal Boiler Server — minimal Boiler-model server with the fluent state-machine builder; Native-AOT publishable.
  • Pump Device Integration Server — minimal Device Integration (Part 100) server using Opc.Ua.Di.Server's fluent builder.
  • Minimal Robot Server — OPC 40010 Robotics with independently configurable RSL/GPOS motion and live OpenUSD transforms.
  • Minimal ISA-95 Server — minimal server hosting the OPC-10030 ISA-95 Common Model together with OPC-10031-4 Job Control V1 and V2, using the typed common-model builder and the in-memory Job Control provider.

More sample projects are maintained in the companion OPC UA .NET Samples repository.

Developer tools

  • OPC UA MCP Server — installable .NET tool and container that exposes OPC UA client operations as MCP tools for LLMs and Copilot.

🔧 Migrating from 1.5.378 to 2.0

The 2.0 release introduces breaking API changes, and comes with a full prescriptive migration guide that links to per-area documentation covering telemetry, packages, source generation, types, encoders, node states, identity, certificates, configuration, sessions / subscriptions, alarms / model change, and TimeProvider.

Most of the mechanical migration work is automated:

  • OPCFoundation.NetStandard.Opc.Ua.MigrationAnalyzer NuGet — install it in your project to get analyzer warnings (UA0001–UA0022)
    • one-click code fixes for the patterns in the guide. Setup steps are in the package's NugetREADME.md.
  • Migration agent skill — the opcua-v20-migration skill walks Copilot / Claude / any coding agent through installing the NuGet, running dotnet format analyzers to apply auto-fixes, and handling the small residual manual patterns. The skill knows which sub-doc to load for each symptom so it stays context-efficient.

If you are still on 1.x and not ready to upgrade, stay on the master378 branch — it continues to receive security and critical-bug fixes.

🤝 Contributing and license

Community contributions are welcome. Fork the repository, make your changes on a branch, and open a pull request; see CONTRIBUTING.md for the contribution workflow.

Contributors must sign the OPC Foundation Contributor License Agreement (CLA). The CLA "I AGREE" gate is presented automatically on your first PR.

The project is licensed under the OPC Foundation MIT License. Report security vulnerabilities via the process documented in SECURITY.md.

📚 Further reading

S
Description
OPC Unified Architecture .NET Standard
Readme
296 MiB
Languages
C# 99.4%
PowerShell 0.2%