Files
UA-.NETStandard/docs/NodeSetExport.md
5899354441 Clarify documentation, migration guidance, and SDK selection (#4823)
# Description

Remove stock phrasing and correct misleading or inconsistent technical
documentation. The initial two passes covered 367 Markdown files,
followed by an interactive review of 169 editorial flags. The U5
interpretation originally deferred in that review has since received the
upstream Mantis answer recorded by #4843; remaining server/spec
follow-ups stay explicit in the CTT log.

- Correct package responsibilities, migration steps, API names,
ownership, protocol descriptions and links. Keep bundled migration
guides synchronized. Preserve historical conclusions as historical
records with separate re-check notes.
- Provide at least two rendered TOC levels throughout `docs/`. Convert
appropriate architecture figures to Mermaid without changing code
examples, transcripts or historical quotations.
- Address the October 19 feedback with concrete setup/migration
instructions, corrected certificate paths and PubSub names, shorter
repeated caveats, consistent XML comments, and a full review of the
Concepts guide. Retain #4839's API corrections.
- Integrate #4841's runtime/performance guidance and review
incoming/recent prose. Preserve dated measurements rather than claiming
new benchmark runs; clarify allocation ratios, startup-only processor
settings, JIT warm-up and the benchmark commit's scope. Missing raw
measurement artifacts and repeat ranges remain tracked by #4842.
- Merge master through `e8c5d800a` in `32c6394b7`. Resolve the CTT log
conflict using the updated Mantis states and OPC answers, retaining
historical framing and re-checks for C28/C32/C43.
- Address the latest naming/index feedback in `adb5bf693`: rename the
guides to `docs/WotCon.md` and `docs/WotNodeSetConversion.md`; move the
provider and DataType-declaration contracts into the conversion guide
and remove `docs/WoT.md`. Rename `samples/DI` to `samples/Di` and
`samples/Isa95` to `samples/ISA95`. Add content-index READMEs to Di,
FluentApi, ISA95, Lds and PubSub; update solution entries, project
references, Docker/CI paths, test fixture paths and documentation links
with exact casing.

**WoT guide scope.** This branch retains the detailed conversion guide
that #4758 had replaced with an anchor stub. Conversion limits, verified
document sets, preservation rules and provider ownership now live
together in `WotNodeSetConversion.md`; binding/runtime guidance remains
in `WotBindings.md` and `WotCon.md`. The design-rationale/test-ledger
prose was shortened, the oversized argument-table cell moved into its
section, and existing anchors preserved.

**SDK policy is a separate, explicit user-directed change.**
`global.json` sets a stable minimum of `10.0.400`, `rollForward:
latestMajor`, and `allowPrerelease: false`. Newer major SDKs are
permitted; CI's explicit SDK pins are unchanged. README, GettingStarted,
DeveloperGuide and Recycling instructions reflect the possible analyzer
differences. The image-contract regression fix accepts compatible stable
SDK images instead of requiring exact equality with the floor.

The latest four rename/index threads are resolved after publication.
Three older threads remain open: universal obsolete-removal timing,
unconditional nonce-strength wording, and a blanket Vision NativeAOT
claim. Existing implementation/evidence constraints are explained in
their inline replies. The two-level TOCs remain as requested.

## Validation

- `git diff --check` and staged diff checks: passed. The untouched
upstream AutoID NodeSet retains its provenance bytes, including two
existing license-header trailing spaces.
- `.\.azurepipelines\validate-migration-plugin.ps1`: passed; 15 bundled
migration documents and manifests synchronized.
- Documentation/path validation: **101** documents retain two rendered
TOC levels (**2,228** entries), with idempotent formatting. **52** new
relative links and their anchors passed exact-case checks. No tracked
references to the old guide/sample paths remain. Both relocated
provider-contract sections are preserved in the destination.
- `dotnet sln UA.slnx list`: passed; shows the renamed Di/ISA95 projects
and the existing FluentApi/Lds/PubSub projects. Updated solution and
pump ProjectReference paths also passed exact-case existence checks.
- Latest focused commands, run from the repository root:

```powershell
# Passed: 61 channel send-order and reconnect tests.
dotnet test tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~UaSCBinaryChannelSendOrderTests|FullyQualifiedName~TcpReconnectKeyAgreementTests' --verbosity minimal

# Passed: 5 pump datasheet tests; builds the renamed pump sample.
dotnet test tests\Opc.Ua.Di.Tests\Opc.Ua.Di.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~PumpDatasheetConformanceTests' --verbosity minimal

# Passed: 4 repository NodeSet path/round-trip tests, including the moved pump models.
dotnet test tests\Opc.Ua.Types.Tests\Opc.Ua.Types.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~RepositorySourceSurvivesSerializedLinkedPartitionsAsync' --verbosity minimal

# Passed: build, zero warnings/errors.
dotnet build samples\ISA95\MinimalIsa95Server\MinimalIsa95Server.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal

# Passed: dependent sample-test project build, zero warnings/errors.
dotnet build tests\Opc.Ua.WotCon.Samples.Tests\Opc.Ua.WotCon.Samples.Tests.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal
```

Earlier focused integration checks passed 2,620 tests across AutoID,
event queues/scheduling, source generation, MCP/package profiles and
WoT. Both reviewed Mermaid diagrams rendered locally without network
access. These checks are not a full solution run.

The full solution has **not** been rerun for this review. Earlier
`dotnet test UA.slnx -p:CustomTestTarget=net10.0 --verbosity quiet` did
not pass: three AOT projects rejected VSTest and 20 Vision tests failed
during graphics initialization with `OutOfMemoryException`. Remaining
long-running tests were stopped at the user's request. A focused Vision
rerun passed 558 tests and reproduced those 20 failures. The earlier
`dotnet test UA.slnx -p:CustomTestTarget=net48 --verbosity quiet` was
blocked by the former SDK pin and was not retried after the policy
change. The user approved proceeding with those limitations documented;
current remote CI is not claimed green.

## Related Issues

- Follow-up #4842 tracks the requested 2.0.2+ benchmark/tuning and
diagnostic-tool documentation refresh. #4841 supplies documentation and
earlier results, not all newly requested measurements.
- #4758 explains the conversion guide's earlier consolidation; the
current provider contracts are now consolidated into
`WotNodeSetConversion.md`.
- #4839 supplies the reviewed API corrections; #4843 supplies the
updated CTT issue record.
- The original prose cleanup and SDK policy were user-requested without
a source issue. No new runtime architecture is introduced by these
documentation edits.

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [ ] 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.
- [ ] 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.

---------

Co-authored-by: Roman Ettlinger <romanett98@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 10:10:55 +02:00

246 lines
7.8 KiB
Markdown

# Client-based NodeSet Export
The OPC UA .NET Standard client library can export a server's address space
to a NodeSet2 XML file. Use the export to document or analyze an address
space, or to import it into another system.
## Contents
- [Overview](#overview)
- [Usage](#usage)
- [Basic Example](#basic-example)
- [Using the Console Reference Client](#using-the-console-reference-client)
- [Supported Node Types](#supported-node-types)
- [Features](#features)
- [Node Attributes Exported](#node-attributes-exported)
- [Namespace Handling](#namespace-handling)
- [References](#references)
- [Limitations](#limitations)
- [MCP server export paths](#mcp-server-export-paths)
- [API Reference](#api-reference)
- [CoreClientUtils.ExportNodesToNodeSet2](#coreclientutilsexportnodestonodeset2)
- [ClientSamples.ExportNodesToNodeSet2](#clientsamplesexportnodestonodeset2)
- [Related Topics](#related-topics)
- [Examples](#examples)
- [See Also](#see-also)
## Overview
The client-based NodeSet export feature enables:
- Browsing and collecting nodes from an OPC UA server
- Converting client-side node representations (`INode`) to server-side representations (`NodeState`)
- Exporting nodes to standard NodeSet2 XML format
- Round-tripping: exported NodeSets can be imported using existing import functionality
## Usage
### Basic Example
The following helper exports the direct children of the Server node from an
existing session. The caller owns the session and output stream. For connection
and trust setup, see [Getting started](GettingStarted.md); for recursive export,
see [Using the Console Reference Client](#using-the-console-reference-client).
```csharp
using System;
using System.Collections.Generic;
using System.IO;
using System.Threading;
using System.Threading.Tasks;
using Opc.Ua;
using Opc.Ua.Client;
/// <summary>
/// Exports nodes browsed through an existing client session.
/// </summary>
public static class NodeSetExportExample
{
/// <summary>
/// Exports the Server node's direct hierarchical children to NodeSet2 XML.
/// </summary>
public static async Task ExportServerChildrenAsync(
ISession session,
ITelemetryContext telemetry,
Stream output,
CancellationToken ct = default)
{
ArgumentNullException.ThrowIfNull(session);
ArgumentNullException.ThrowIfNull(telemetry);
ArgumentNullException.ThrowIfNull(output);
var browser = new Browser(session)
{
BrowseDirection = BrowseDirection.Forward,
ReferenceTypeId = ReferenceTypeIds.HierarchicalReferences,
IncludeSubtypes = true,
NodeClassMask = 0
};
ArrayOf<ReferenceDescription> references =
await browser.BrowseAsync(ObjectIds.Server, ct).ConfigureAwait(false);
var nodes = new List<INode>();
for (int i = 0; i < references.Count; i++)
{
INode? node = await session.NodeCache.FindAsync(references[i].NodeId, ct)
.ConfigureAwait(false);
if (node is not null)
{
nodes.Add(node);
}
}
ct.ThrowIfCancellationRequested();
var systemContext = new SystemContext(telemetry)
{
NamespaceUris = session.NamespaceUris,
ServerUris = session.ServerUris
};
CoreClientUtils.ExportNodesToNodeSet2(systemContext, nodes, output);
}
}
```
Browsing and node reads are asynchronous; the existing export helper writes
the collected nodes to XML synchronously.
### Using the Console Reference Client
The console reference client (`ClientSamples` class) includes a helper method for exporting nodes:
```csharp
// Browse and collect nodes using the existing helper
IList<INode> nodes = await clientSamples.FetchAllNodesNodeCacheAsync(
uaClient,
ObjectIds.ObjectsFolder, // Starting node
fetchTree: true, // Recursively browse the tree
addRootNode: true, // Include the root node
filterUATypes: true, // Filter out namespace 0 nodes
clearNodeCache: true
);
// Export to NodeSet2 file
clientSamples.ExportNodesToNodeSet2(session, nodes, "address-space.xml");
```
## Supported Node Types
The export functionality supports all standard OPC UA node types:
- **Object nodes** - Objects and their properties
- **Variable nodes** - Variables with their values and data types
- **Method nodes** - Methods with their executable status
- **ObjectType nodes** - Object type definitions
- **VariableType nodes** - Variable type definitions
- **DataType nodes** - Data type definitions
- **ReferenceType nodes** - Reference type definitions
- **View nodes** - View definitions
## Features
### Node Attributes Exported
For each node, the following attributes are exported (where applicable):
- NodeId
- BrowseName
- DisplayName
- Description
- WriteMask and UserWriteMask
- References to other nodes
- Type-specific attributes (e.g., DataType for variables, EventNotifier for objects)
### Namespace Handling
The export functionality handles:
- Multiple namespaces
- Namespace URIs are included in the exported NodeSet
- NodeIds are mapped to namespace indices
### References
All references between nodes are preserved in the export, including:
- Hierarchical references (e.g., HasComponent, HasProperty)
- Type definition references (e.g., HasTypeDefinition)
- Organizing references
- Custom reference types
## Limitations
- The export creates a snapshot of the address space at the time of browsing
- Dynamic values are captured as they exist at export time
- Not all server-specific internal state may be preserved
- Complex type definitions require the complex types system to be loaded
### MCP server export paths
The MCP server's `ExportNodeSet` tools use a separate, per-user export root.
`OpcUaMcpOptions.NodeSetExportRoot` takes precedence over the
`OPCUA_MCP_EXPORT_ROOT` environment variable, followed by the per-user default.
Both relative and absolute output paths must remain inside that root. The MCP
writer rejects existing files, filesystem reparse points and unsafe Unix
directory permissions, and creates new output files exclusively rather than
truncating an existing destination.
Configure the root so no untrusted local account can replace its path
components. The managed path checks do not pin directory handles across the
entire operation, so a concurrently writable shared directory is not a
supported export root. Existing destinations must be moved or removed
explicitly before exporting again.
## API Reference
### CoreClientUtils.ExportNodesToNodeSet2
```csharp
public static void ExportNodesToNodeSet2(
ISystemContext context,
IList<INode> nodes,
Stream outputStream)
```
**Parameters:**
- `context` - System context containing namespace and server URI information
- `nodes` - List of nodes to export
- `outputStream` - Stream to write the NodeSet2 XML to
**Exceptions:**
- `ArgumentNullException` - If any parameter is null
### ClientSamples.ExportNodesToNodeSet2
```csharp
public void ExportNodesToNodeSet2(
ISession session,
IList<INode> nodes,
string filePath)
```
**Parameters:**
- `session` - Active session to use for namespace information
- `nodes` - List of nodes to export
- `filePath` - Path where the NodeSet2 XML file will be saved
## Related Topics
- [Working with ComplexTypes](ComplexTypes.md)
- [Console Reference Client](../samples/Reference/ConsoleReferenceClient/README.md)
- OPC UA NodeSet2 XML Schema specification
## Examples
For complete examples of using the NodeSet export functionality, see:
- `tests/Opc.Ua.Client.Tests/NodeSetExportTest.cs` - Unit tests demonstrating various export scenarios
- `samples/Reference/ConsoleReferenceClient/ClientSamples.cs` - Integration in the reference client
## See Also
- [OPC UA Specification Part 6 - Mappings](https://reference.opcfoundation.org/Core/Part6/v105/)
- NodeSet2 XML Schema: `src/Opc.Ua.Core/Schema/UANodeSet.xsd`