AliasNames sample: follow-up work once the SDK is updated to current master

[romanett]

Type of issue

• Enhancement

Current Behavior

The Alias Names sample (OPC UA Part 17) added in #849 for #822 is built against 2.0.0-preview.2, the version this repository pins. That version ships the full Opc.Ua.Server.AliasNames / Opc.Ua.Client.AliasNames API surface, but not the alias node materialization pass. Current SDK master (present from 2.0.262.32744-preview onward) adds it, plus a fix for a spec deviation the sample currently records as a known issue.

The sample was written to degrade honestly rather than to work around the gap, and the affected spots are documented in Workshop/AliasNames/README.md. This issue collects what should be revisited when the pin moves, so none of it is lost.

Expected Behavior

After the SDK bump the sample demonstrates the whole of Part 17 §6.2/§9 that the stack supports, and carries no stale "not available in this SDK version" caveats.

What changes

1. A test will go red on the bump — this one is not optional

InMemoryAliasNameStore.BumpLastChangeWithAncestors(NodeId) is new in 2.0.262, and its own summary says it bumps

the mutated category's LastChange and — per Part 17 §6.3.1/§9.2 […] — every ancestor category's too

That is exactly the deviation AliasNamesNodeManagerTests.AChangeInASubCategoryAdvancesTheLastChangeOfItsParent currently records through the repo's KnownIssue.RecordAsync helper: on preview.2 a change in PlantTags/Reactor advances that category's LastChange but leaves the PlantTags root's node reading the old value, so a client watching only the root misses it.

KnownIssue.RecordAsync deliberately fails when its check starts passing, with "This is recorded as a known issue, but it passed […] Remove the KnownIssue.RecordAsync wrapper and let the assertion stand on its own." So the moment the SDK is bumped, tier 1.5 goes red until someone unwraps that assertion. That is the mechanism working as designed, but whoever does the bump should expect it.

Action: remove the KnownIssueAsync wrapper in Tests/SampleNodeManagers.Tests/AliasNamesNodeManagerTests.cs, let the two assertions stand plainly, and drop the corresponding paragraph from the sample README's Tests section.

2. Turn on materialization for the standard well-known categories

New in 2.0.262:

• DiagnosticsNodeManager.MaterializeRegisteredAliasNameNodesAsync(externalReferences, ct)
• AliasNameNodeMaterializer, IAliasNameMaterializerHost, AliasNameNodeManagerLog
• AliasNameReservedChildIds / AliasNameReservedMethodIds — the NodeIds the OPC Foundation reserves for the optional children (Aliases.FindAliasVerbose = i=24054, TagVariables.LastChange = i=32854, …)
• AliasNameNodeManagerOptions.MaterializeAliasNodes (default true)

This unlocks two things the sample currently cannot show:

• Browsable AliasNameType nodes (§6.2) — one instance per alias, with AliasFor references to its targets and the inverse HasAlias on each local target. The OPC Foundation CTT browses for these, so this is the conformance-relevant half.
• The optional Methods on the standard categories — FindAliasVerbose, AddAliasesToCategory, DeleteAliasesFromCategory and LastChange instantiated at their reserved NodeIds.

Calling the pass requires a DiagnosticsNodeManager subclass that overrides CreateAddressSpaceAsync and calls MaterializeRegisteredAliasNameNodesAsync after base. Quickstarts.ReferenceServer does this in ReferenceServerConfigurationNodeManager; StandardServer.CreateMainNodeManagerFactory looks like the substitution hook, but please confirm rather than take my word for it — the XML doc on that member is copy-pasted from CreateMasterNodeManager and does not describe what it actually returns.

3. Widen the standard descriptor's capabilities

AliasNamesServer.ConfigureStandardTagVariables currently declares:

new AliasNameCategoryDescriptor(
    Opc.Ua.ObjectIds.TagVariables,
    new QualifiedName(Opc.Ua.BrowseNames.TagVariables),
    AliasNameCapabilities.None);   // <- the mandatory FindAlias, and nothing without a node

with a comment explaining that anything more would advertise Methods the address space cannot serve. With materialization in place this should become AliasNameCapabilities.All, and that comment should go.

4. Documentation

• Workshop/AliasNames/README.md — the Notes for implementers bullet about the missing materialization pass, the §6.2 bullet after it, and the Browsable / Methods rows of the standard-vs-application-defined comparison table all become wrong.
• The What this sample does not cover section should be re-checked; §6.2 browsing moves out of it.
• docs/TESTING.md — the tier 1.5 row for AliasNames can gain the browsable-alias-node behaviour if tests are added for it.

5. Worth adding once materialization exists

New tier 1.5 coverage for the newly reachable surface:

• an AliasNameType node is browsable under TagVariables, its BrowseName carries the alias name, and it has AliasFor references to its targets;
• the inverse HasAlias reference appears on the target node;
• FindAliasVerbose answers on the standard TagVariables (it currently only works on the application-defined categories);
• a returned alias name resolves via TranslateBrowsePathsToNodeIds, which is the round trip the re-homing of ns=0 BrowseNames exists to make work.

Notes

• The client needs no changes. I diffed the full Alias* API surface of Opc.Ua.Client between 2.0.0-preview.2 and 2.0.262.32744-preview: identical, nothing added or removed. All the movement is server-side.
• One server member disappears: AliasNameNodeManager.BuildCategoryTree(AliasNameCategoryDescriptor). The sample does not call it, but it is worth a grep across the repo during the bump in case anything else does.
• AliasNameMethodDispatcher.HasSecureAdminAccess(ISystemContext) is newly documented — relevant only if a sample ever wants to explain the SecurityAdmin + SignAndEncrypt gate rather than just demonstrate it.
• Version numbers above are from 2.0.262.32744-preview, the first cached build I could verify these against. Whoever does the bump should confirm against whatever master actually publishes.

Related: #822, #849. Reference for all of the above: docs/AliasNames.md on UA-.NETStandard master, which already documents the post-materialization behaviour.