# Description Adds a way to publish a numbered release-line preview (e.g. `2.0.0-preview.6`) to nuget.org. Since #4513, `nuget-publish.yml` pushes previews only to GitHub Packages, and `release.yml` (the only nuget.org path) refused every non-stable candidate. That left no way to continue the `2.0.0-preview.N` series on nuget.org (last published there: `2.0.0-preview.5`). ## Changes - **`release.yml`** gains a `channel` input (`stable` | `preview`, default `stable`). - `stable` behaves exactly as before. - `preview` accepts only a public release-line preview, `M.m.p-preview.N` with no commit id, from the matching canonical `release/M.m` branch. `master` / PR builds (`-preview.N.g<sha>`) are rejected. - The candidate manifest's recorded `channel` must equal the dispatched one, so a stable promotion can never publish a preview by accident, or the reverse. - **`package-version-policy.ps1`**: new `Test-PromotablePreviewPackageVersion`, and an `-AllowPreview` switch on `Test-CanonicalReleaseBranchForPackageVersion`. Callers without the switch (the stable gate in `nuget-publish.yml`) behave exactly as before. - **`docs/ReleaseProcess.md`**: new "Preview release" procedure, including how to pick the preview number with `versionHeightOffset`. - **Tests**: predicate cases, the `-AllowPreview` switch, and a pin that `release.yml` defaults to `stable` and relaxes the gate only for `channel=preview`. ## GitHub Packages preview feed is unchanged - `nuget-publish.yml` is not touched. `master` keeps auto-publishing `2.0.0-preview.<height>.g<sha>` to GitHub Packages, and release-branch builds keep pushing their own `<base>-preview.N` there. - The commit-id suffix means `master` versions can never collide with a bare `2.0.0-preview.N`. - For a preview, `release.yml`'s GitHub Packages push is a verified no-op. The candidate's own `nuget-publish.yml` run already pushed those bytes, and the existing identity preflight and post-push check prove they match. ## Getting `2.0.0-preview.6` after merge 1. Cut `release/2.0` from `master` after this merges. `release.yml` executes the policy script from the candidate commit, so that commit must contain this change. 2. On `release/2.0`, commit a `versionHeightOffset` so the build lands on `.6`. Verified locally with nbgv 3.10.94: at the current `master` tip (height 24), one commit setting `-19` yields `2.0.0-preview.6` and the next yields `.7`. Recompute for the actual cut point with `nbgv get-version -v NuGetPackageVersion`. 3. Dispatch `release.yml --ref release/2.0 -f release_run_id=<run> -f channel=preview`, with a dry run first. `2.0.0-preview.6` is currently free: nuget.org has `.2`–`.5`, and the retired `release/2.0.0` pushed up to `.5` to GitHub Packages. ## Related Issues - Follow-up to #4513. Supersedes the `master` → `release/2.0.0` merge attempts #4566 / #4570; `release/2.0.0` is retired and cannot publish. ## Checklist - [ ] I have signed the [CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf) and read the [CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md) doc. - [x] I have added tests that prove my fix is effective or that my feature works and increased code coverage. - [x] I have added all necessary documentation. - [ ] I have verified that my changes do not introduce (new) build or analyzer warnings. - [ ] I ran **all** tests locally using the **UA.slnx** solution against at least .net **framework** and .net **10**, and all passed. - [ ] I fixed **all** failing and flaky tests in the CI pipelines and **all** CodeQL warnings. - [ ] I have addressed **all** PR feedback received. Locally: `PackageVersionPolicyTests` + `NuGetPackageSetValidationTests` on net10.0, 96/96 passed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
OPC UA .NET Standard stack documentation
These guides lead from a first working application to advanced and experimental capabilities. Follow the numbered stages when you are learning. Choose only the paths that match your application, or use the contents list to find a feature.
- New to the SDK? Start with Getting started, read OPC UA concepts, then build your first information model.
- Upgrading from 1.5.x? Read What's New in 2.0, then follow the Migration Guide.
- Contributing to this repository? See Contributing and maintaining the SDK.
Contents
- How to use this index
- 1. Get started
- 2. Build your application
- 3. Add data types and application services
- 4. Use companion models
- 5. Prepare for production
- 6. Advanced integration, reliability, and scale
- 7. Draft and experimental capabilities
- Reference and upgrade
- Contributing and maintaining the SDK
How to use this index
Each stage builds on the earlier ones, but you do not need to read every guide. After stage 1, choose the client, server, or PubSub path. Stages 3 to 7 are optional; use the guides your application needs. A stage or group names the knowledge it assumes.
Labels describe the maturity of a package or model:
- Preview package: the package family keeps a
-previewversion, even when the core packages are stable. See Versioning. - Draft model: the guide implements a working-group draft specification. Its namespace URIs and NodeIds are provisional.
- Experimental: the guide marks the feature as experimental.
These labels are independent of difficulty. An advanced guide can describe a stable feature, and a released specification can ship in a preview package.
1. Get started
Run a client and server, then learn the terms that the other guides use.
- Getting started — run the minimal samples, or build a client and server from NuGet packages.
- OPC UA concepts — applications, endpoints, sessions, the address space, values, subscriptions, and PubSub.
- Your first information model — add a model to the Getting started server, then read, write, and call it from the client.
- Sample catalogue — minimal, reference, PubSub, and companion-model applications.
- Packages and supported platforms — choose packages and target frameworks.
2. Build your application
Choose the path for your application. The paths are independent: for example, a PubSub application needs neither a client nor a server.
Client path
Assumes Getting started.
- Dependency injection: client feature — configure a client in the .NET Generic Host.
- Managed sessions — connect, recover from connection loss, and close. To compare the managed and classic session APIs, see choosing a session API.
- Read, write, and call methods — resolve namespace URIs and browse paths, check the status of each operation, and call methods through a client generated from the model.
- Subscriptions — callback subscriptions for long-lived monitoring and streams for short observations.
Server path
Assumes Getting started.
- Dependency injection: server feature — host a server and configure its endpoints, security, and node managers.
- Node managers: start with a model — generate a node manager from your model and attach callbacks. Your first information model is a complete example.
- Runtime NodeSets — load NodeSet2 models without generated code when models change independently of your application.
- Asynchronous server support — implement service and node-manager callbacks asynchronously.
PubSub path
A PubSub application needs neither a client nor a server, so the Getting started exercise and the other two paths are optional here.
- Concepts: client/server and PubSub — publishers, subscribers, and datasets.
- Run a first publisher and subscriber — exchange signed and encrypted messages on one computer with the reference PubSub sample.
- PubSub guide — the fluent builder, hosting, configuration, encodings, and security.
- Transport selection — UDP, Ethernet, MQTT, and Kafka.
3. Add data types and application services
Assumes the client or server path. Choose the capabilities your application needs.
Data types and models
- Source-generated data types — generate encodeable implementations for your own structures.
- Complex types — decode server-defined structures and enumerations at run time.
- Model dependencies — compose models that depend on other models.
- NodeId assignment — control the identifiers of nodes created at run time.
- Schema generation — produce XSD, BSD, and JSON schemas for data types.
Application services
- State machines — define, drive, and observe state transitions.
- Alarms and conditions — raise, acknowledge, and stream alarms. Alarm conditions use state machines, for example for shelving.
- Historical access — store and read value and event history.
- Aggregates — calculate processed history; read historical access first.
- File system client — transfer files through the standard file objects.
- Alias names — find nodes through named aliases.
- Node management — let clients add and delete nodes and references.
- Model change tracking — keep client caches current when the address space changes.
- NodeSet export — export a server's address space to NodeSet2 XML.
4. Use companion models
Companion specifications define models for particular industries and device types; Concepts explains how they relate to the base model. These libraries assume the server path and, for typed client access, the client path. The packages load the models that each model depends on.
- Device Integration (OPC 10000-100; preview package) — devices, topology, and locking.
- Software update (OPC 10000-100; preview package) — software package storage, installation, and confirmation. Read Device Integration first.
- ISA-95 (OPC 10030 and OPC 10031-4; preview package) — the common model and job control.
- Positioning (OPC 10000-210 and OPC 10000-211; preview package) — relative frames and geographic positions.
- Robotics (OPC 40010-1; preview package) — motion-device systems, based on the Industrial Automation and Device Integration models. The guide's draft Robot Intent model is listed in stage 7.
- WoT connectivity (OPC 10100-1; preview package) — connect Web of Things assets. Its registry extension is listed in stage 7.
For more examples, including the Pumps and Machinery models, see the companion-model samples.
5. Prepare for production
Builds on the certificate trust you used in Getting started. Before you deploy a client or server, work through the production readiness checklist. It links to these guides for the details:
- Certificates — certificate stores, trust, and chain validation.
- Identity providers — authenticate users on clients and servers.
- Role-based user management — map identities to roles and permissions.
- Certificate manager — certificate lifecycle, rotation, and remote updates.
- Diagnostics — logging, metrics, tracing, auditing, and packet capture.
- Rate limiting — admission limits and busy signals during connection storms.
- Server resource isolation — per-caller limits and reserved capacity for startup and recovery.
- Profiles and facets — implemented profiles and platform boundaries.
- Container reference server — run the reference server in a container.
6. Advanced integration, reliability, and scale
Each group names the stages it assumes.
Transports and integration
Assumes the client or server path.
- Transports — UA-TCP, HTTPS, and WebSocket transports.
- REST binding — OpenAPI mapping, encoding negotiation, and HTTP authentication.
- Reverse Connect — server-initiated connections.
- PubSub external-server adapter — bind PubSub to an OPC UA server through a managed client session. Assumes the client and PubSub paths.
- PubSub transcoding — convert encodings, values, and metadata between PubSub messages.
- MCP server — let AI agents browse, read, write, and diagnose OPC UA servers.
- WoT / NodeSet conversion and WoT protocol bindings — convert Thing Descriptions and add protocol bindings. Read WoT connectivity first.
Session recovery and performance
The subscription guides assume the client path; the sizing guides assume Diagnostics.
- TransferSubscriptions — move server subscriptions to a new session.
- Durable subscriptions — keep subscriptions and queued notifications while clients are disconnected.
- Server scalability — sizing limits and bottlenecks.
- Benchmarks — measured performance and methodology.
Security infrastructure and fleet management
Assumes stage 5.
- ECC profiles — elliptic-curve security policies and their platform requirements.
- Crypto providers — replace the platform cryptography and keep private keys in hardware.
- Provisioning mode — configure a new server securely before exposing application data.
- Global Discovery Server — application registration and central certificate management.
- GDS sample — a runnable onboarding workflow.
- AuthorizationService — issue access tokens.
- KeyCredentialService — manage credentials for services that are not OPC UA. Its issued-token bridge is listed in stage 7.
High availability and deployment
Assumes a working single server and stage 5.
- High availability (preview package) — redundancy, failover, and distributed state.
- Replica-consistent NodeIds (preview package) — keep node identifiers identical across replicas; required before replicating an address space.
- Kubernetes (preview package) — cluster deployment, discovery, readiness, and secrets. Read high availability first.
- PubSub high availability (preview package) — redundant publishers and subscribers. Assumes the PubSub path.
Native AOT publishing
Publish an application as a native executable without a JIT compiler; start with Native AOT: publish an application. Feature-specific guidance:
- Servers with generated node managers
- Applications hosted with dependency injection
- PubSub applications
7. Draft and experimental capabilities
These guides implement working-group drafts or experimental extensions. Namespace URIs, NodeIds, and APIs can change before the specifications are published, so evaluate them before you depend on them in production. Each guide describes its current limitations.
- xRegistry (draft model; preview package) — the generic registry base model, resource storage, and federation.
- AI model management (draft model; preview package) — model catalogues, deployments, inference, and learning jobs. Builds on xRegistry.
- Vision (draft model; preview package) — perception, media, feedback, and client workflows.
- Robot Intent (draft model; preview package) — task-level motion commands. Does not require the Robotics model.
- OpenUSD (draft models; preview package) — bind values to OpenUSD scenes and materialize scenes in the address space.
- WoT Connectivity 1.1 registry (draft model; preview package) — registry and materialization. Read WoT connectivity first.
- KeyCredential issued-token bridge (experimental).
These samples combine several draft or preview capabilities. Read the guides for their models first:
- Bin picking cell — Robot Intent, Vision, and an OpenUSD scene.
- Visual inspection cell — Vision, AI model management, and ISA-95 job control.
- WoT aggregation sample — load Device Integration, Machinery, and Pumps models from WoT documents through the WoT Connectivity 1.1 registry, and bind them to two OPC UA source servers.
- Generator sample model (draft model) — generating-set simulation and scene composition.
Reference and upgrade
- What's New in 2.0 — a summary of new capabilities.
- Migration Guide — upgrade from 1.5.378, with topic-specific 2.0 guides and PubSub migration.
- Reference client — command-line configuration and transport profiles.
- Reference server — hosting and compliance-test setup.
- Reference PubSub client — publisher, subscriber, and external-adapter modes.
The Windows Forms reference applications are maintained in the Samples repository.
Contributing and maintaining the SDK
These documents describe building and maintaining this repository, not using the SDK in an application:
- Developer Guide — prerequisites, build, tests, and coding conventions.
- Continuous integration — pipelines and coverage gates.
- Native AOT test harness — build, run, and extend the Native AOT compatibility tests.
- Release process — release branches, versioning, backports, and recovery.
- Redundancy sample tests — process-level failover and soak validation.
- Fuzz testing — encoder, certificate, and network campaigns.