Coordinate with OtOpcUa OPC UA SDK 2.0 upgrade (lmxopcua#782): wire-compat check of the DCL adapter #125

New Issue

2026-11-11T11:55:12-05:00

dohertj2 commented

2026-11-11 11:55:12 -05:00

Cross-repo coordination for lmxopcua#782 (OtOpcUa OPC Foundation SDK upgrade 1.5.378.106 → 2.0.1). The owner decided on 2026-11-11 to coordinate now, in parallel with the server soak lmxopcua#799.

State: OtOpcUa master now pins OPCFoundation.NetStandard.Opc.Ua.* 2.0.1 on the server side. Its rollout is gated on lmxopcua#799 (lifecycle soak RSS guard), #800 (Windows native install / reused-PKI restart) and #801 (AVEVA history, consumer compatibility, paired-cluster rollout). ScadaBridge still pins 1.5.378.106 (Directory.Packages.props: Client in DataConnectionLayer, Server in DataConnectionLayer.Tests).

Asks for ScadaBridge:

Wire compatibility (needed before lmxopcua#801): run the DCL OPC UA adapter, on its current 1.5.378.106 client, against an SDK2 OtOpcUa server (the docker-dev rig, opc.tcp://localhost:4840/:4841). Cover connect/secure channel (incl. #121's certificate path), browse of both namespaces (https://zb.com/otopcua/raw, /uns), reads, subscriptions, writes, Server-object alarm subscription + ConditionRefresh on reconnect, and redundancy failover between the pair. Record any behaviour difference.
Decide whether ScadaBridge also moves to 2.0.x, and when. That is not required for wire compatibility, but the two stacks would otherwise diverge (async-API and transport rework in 2.0).
Note any test that uses the in-process Opc.Ua.Server (DataConnectionLayer.Tests) as a stand-in for OtOpcUa; it would no longer match the real server's SDK.

Relates to: lmxopcua#782, lmxopcua#799, lmxopcua#801.

Cross-repo coordination for lmxopcua#782 (OtOpcUa OPC Foundation SDK upgrade 1.5.378.106 → 2.0.1). The owner decided on 2026-11-11 to coordinate now, in parallel with the server soak lmxopcua#799. **State:** OtOpcUa master now pins `OPCFoundation.NetStandard.Opc.Ua.*` **2.0.1** on the server side. Its rollout is gated on lmxopcua#799 (lifecycle soak RSS guard), #800 (Windows native install / reused-PKI restart) and #801 (AVEVA history, consumer compatibility, paired-cluster rollout). ScadaBridge still pins **1.5.378.106** (`Directory.Packages.props`: Client in DataConnectionLayer, Server in DataConnectionLayer.Tests). **Asks for ScadaBridge:** 1. **Wire compatibility (needed before lmxopcua#801):** run the DCL OPC UA adapter, on its current 1.5.378.106 client, against an SDK2 OtOpcUa server (the docker-dev rig, `opc.tcp://localhost:4840`/`:4841`). Cover connect/secure channel (incl. #121's certificate path), browse of both namespaces (`https://zb.com/otopcua/raw`, `/uns`), reads, subscriptions, writes, Server-object alarm subscription + ConditionRefresh on reconnect, and redundancy failover between the pair. Record any behaviour difference. 2. **Decide whether ScadaBridge also moves to 2.0.x,** and when. That is not required for wire compatibility, but the two stacks would otherwise diverge (async-API and transport rework in 2.0). 3. Note any test that uses the in-process `Opc.Ua.Server` (DataConnectionLayer.Tests) as a stand-in for OtOpcUa; it would no longer match the real server's SDK. Relates to: lmxopcua#782, lmxopcua#799, lmxopcua#801.

dohertj2 added the type:followup priority:p2 cross-repo labels 2026-11-11 11:55:12 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/ScadaBridge#125