Files

47 lines
2.5 KiB
Markdown

# Actual ScadaBridge consumer compatibility
This isolated process references the real ScadaBridge `OpcUaDataConnection` and
`RealOpcUaClient`, with their own dependency graph. It never loads the candidate
SDK into that process. The verified consumer source is
`0e89966da670e289bd875166295bb0e85d8cf8b2`, pinned to SDK 1.5.378.106.
Build with an explicit clean consumer checkout:
```sh
dotnet build scripts/validation/scadabridge-sdk-compatibility/Probe.csproj \
-c Release -p:ScadaBridgeSourceRoot=/absolute/ScadaBridge
```
First build the separate application hosts with the parent
`scripts/e2e/test-opcua-sdk-compatibility.ps1` harness. Then choose a new output
directory and pass its original and candidate `ProcessHost.dll` paths:
```sh
python3 scripts/validation/scadabridge-sdk-compatibility/run.py \
--baseline-host /absolute/matrix/build-baseline/bin/Release/net10.0/ProcessHost.dll \
--candidate-host /absolute/matrix/build-candidate/bin/Release/net10.0/ProcessHost.dll \
--probe scripts/validation/scadabridge-sdk-compatibility/bin/Release/net10.0/Probe.dll \
--results /absolute/fresh-consumer-evidence
```
The helper runs four separate consumer/server pairs: each application version
with None and SignAndEncrypt. None is enabled only in its own test fixture;
the ordinary compatibility host remains strict SignAndEncrypt. The task key is
generated per process pair, issuer/trusted/rejected stores are task-local, and
server public certificates are explicitly copied. Autoaccept remains false.
Never commit an entire output directory: it contains the fixture's private PKI.
The consumed subset covers API-key activation, raw/UNS scalar and Int32[]
roundtrips, durable hierarchical browse including the native alarm, data quality
and timestamps, alarm filter/ConditionRefresh and disconnect/reconnect. History
and Part 9 acknowledgment are not exposed by the inspected consumer interfaces;
the parent Shared/CLI matrix covers those application services instead.
ScadaBridge#121 is a reproduced preexisting limitation: SignAndEncrypt fails
against **both** original and candidate servers because the consumer does not
configure an application certificate. A matching baseline failure is evidence,
not a secure-channel pass. The runner retains the nonzero result and each actual
failure; it does not loosen trust or change expected results to return success.
The current None subset and the missing secure identity must be reported
separately. No ScadaBridge production source or user PKI is modified.