# Description > **Stacked PR**: based on `romanett/server-di-config-xml-e30c4f` (#4325) so the diff shows only the client changes. Once #4325 merges this will be rebased onto `master`. Gives the **client** DI surface the same migration path for existing configuration XML files that #4325 gave the server: applications that already own a classic `MyClient.Config.xml` can pass it to `AddClient` and keep **all** of their settings. New API surface: - `AddClient(string configurationFile, Action<OpcUaClientOptions>? configure = null)` loads the `ApplicationConfiguration` from the file; the optional callback configures the remaining client options (session endpoint, identity, reverse connect, ...). - `AddClient(Stream configurationStream, ...)` for documents that are not files on disk, e.g. embedded resources. The stream is read once and disposed after loading. - `OpcUaClientOptions.ConfigurationFile` / `ConfigurationStream` back the overloads, so the options-callback route works too and the file path can be bound from configuration (`OpcUa:Client:ConfigurationFile`). - `OpcUaClientOptions.ConfigureLoadedConfiguration` runs after the document is loaded and validated but before the application-instance certificate check, for code-side overrides of individual file settings. Mechanism and behavior: - A new internal `ClientSuppliedConfigurationProvider` implements `IOpcUaApplicationConfigurationProvider` and plugs into the client's existing configuration-provider seam. The document loads **lazily on first use** — the first session connect, reverse-connect startup, or an explicit `GetAsync` — through `ApplicationInstance.LoadApplicationConfigurationAsync`, so every setting (security configuration, certificate stores, transport quotas, client configuration) applies exactly as on the classic path, including localhost fix-up. - The load **ensures the application-instance certificate** (mirroring the shared `ConfigureApplication(...)` provider), which the pre-existing manual workaround — pre-loading and assigning `OpcUaClientOptions.Configuration` — never received. DI-registered `ICertificateManager` / `ICertificatePasswordProvider` are honored. Single-flight loading; `IAsyncDisposable` like the shared provider. - The supplied document is authoritative and takes precedence over a shared application registered with `ConfigureApplication(...)`. Ambiguous combinations are rejected eagerly at `AddClient` with clear `InvalidOperationException`s: file + stream, document + explicit `Configuration`, document + application identity properties, and a white-space path arriving through configuration binding. The start-time `IValidateOptions` validator accepts a supplied document as a configuration source. - `ConnectManagedSessionAsync` publishes the lazily loaded configuration onto the resolved options after `GetAsync`, so the channel manager and session builder see it exactly as on the other configuration paths; reverse connect consumes the provider through its existing async-startup path unchanged. Coverage: new `ClientConfigurationFileTests` fixture (8 tests) — loading from file and stream with assertions on the document settings, the override callback, the certificate bootstrap, provider caching and lazy semantics, precedence over `ConfigureApplication`, load failure for a missing file, argument validation, ambiguous-combination rejection, configuration-section binding, and validator acceptance. All 323 existing ClientBuilder tests and all 180 server hosting tests (including the combined client+server fixtures) pass; `Opc.Ua.Client` builds warning-free on net472, net8.0, and net10.0 (AOT analyzers). Docs: new "Client: using an existing configuration XML file" section in `docs/DependencyInjection.md` with cross-links from the server section, an updated pointer in the 2.0 migration guide, and a NuGet README mention. ## Related Issues - Fixes #4327 - Stacked on #4325 (server-side counterpart) ## Checklist _Put an `x` in the boxes that apply. You can complete these step by step after opening the PR._ - [x] 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. - [x] 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. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: marcschier <11168470+marcschier@users.noreply.github.com>
8.5 KiB
Configuration and State Persistence
When to read this: Read this for
ApplicationConfigurationchanges, the removed Data-Contract serializer, Newtonsoft removal fromOpc.Ua.Core, the newParseExtension/UpdateExtensionsignature, and session / browser state persistence.
Configuration
Data Contract Serializer support removed
Because Data Contract serialization is not AOT compliant and does not support trimming, all use of DataContract in the configuration has been removed. Instead, the source generator enables generating IEncodeable implementations using the DataType and DataTypeField attributes which are now consequently used for all configuration. Because the configuration is now IEncodeable the existing encoders and decoders (in particular the new XmlParser which parses Xml and allows out of order fields) compliant with Part 6 can be used to serialize and deserialize all configuration and configuration extensions.
Generated Data types still support DataContract based serialization, however, consider this a deprecated feature.
All configuration DTO classes (ApplicationConfiguration, ServerConfiguration, TraceConfiguration, TransportConfiguration, ServerSecurityPolicy, OAuth2ServerSettings, OAuth2Credential, GlobalDiscoveryServerConfiguration, CertificateGroupConfiguration, BrowserOptions, etc.) migrated from [DataContract]/[DataMember] to source-generated [DataType]/[DataTypeField] attributes and are now partial classes.
ApplicationConfiguration.LoadWithNoValidationusesXmlParser/IEncodeable.Decode(). Existing XML config files should remain loadable. Applications moving to the dependency-injection surface can pass such a file directly toservices.AddOpcUa().AddServer("MyServer.Config.xml")or.AddClient("MyClient.Config.xml")and keep every setting from it — see Migrating with an existing configuration XML file and Client: using an existing configuration XML file.- Browser and session state persistence switched from XML to OPC UA Binary encoding. Old persisted files cannot be loaded — delete and re-save.
SecuredApplicationusesSecuredApplicationEncodinghelpers instead ofDataContractSerializer.
Change code as follows:
- Replace
[DataContract(Namespace = ...)]with[DataType(Namespace = ...)]and[DataMember(...)]with[DataTypeField(...)]on custom configuration subtypes. - If the old namespace expression references a
Namespacesconstant generated from a model file in the same project, replace it with the URI literal or aconst stringfrom ordinary source. Same-run generated constants are unavailable while[DataType]attributes are analyzed and now produceMODELGEN021. - Add the
partialkeyword to any subclass of these configuration types. - Custom configuration extension types must implement
IEncodeable(the[DataType]source generator handles this automatically forpartialclasses). - Code using reflection to inspect
[DataContract]/[DataMember]attributes must switch to[DataType]/[DataTypeField].
TraceConfiguration apply APIs removed
The legacy TraceConfiguration application path (TraceConfiguration.ApplySettings() and the fluent builder methods SetOutputFilePath(...), SetDeleteOnLoad(...), SetTraceMasks(...)) has been removed. Logging/tracing setup must now be done via ITelemetryContext and ILoggerFactory.
If your startup code used these APIs, remove those calls and configure logging providers directly on your telemetry context instead.
MinMetadataSamplingInterval removed, MinSupportedSamplingInterval added
ServerConfiguration.MinMetadataSamplingInterval and the fluent
SetMinMetadataSamplingInterval(int) builder method have been removed. In
1.5.378 the setting defaulted to 1000 but was never read by the stack, so
whatever value you configured had no effect on any monitored item.
2.0 adds ServerConfiguration.MinSupportedSamplingInterval (a double, in
milliseconds) in the same position of the XML schema, exposed by the fluent
builder as SetMinSupportedSamplingInterval(double). Unlike its predecessor it
is applied: it is published in Server.ServerCapabilities.MinSupportedSampleRate
and acts as a server-wide lower bound when the sampling interval of a monitored
item is revised.
These are two different settings, not a rename. Do not carry the old value
across — in 1.5.378 it was inert, so reusing it silently introduces a sampling
floor that changes the revisedSamplingInterval your clients receive. Delete
the old element and only add the new one if you actually want that floor:
<!-- before: had no effect in 1.5.378 -->
<MinMetadataSamplingInterval>1000</MinMetadataSamplingInterval>
<!-- after: simply drop it to keep 1.5.378 behaviour -->
<!-- ...or opt in deliberately, knowing clients will now be revised up -->
<MinSupportedSamplingInterval>1000</MinSupportedSamplingInterval>
// before: had no effect in 1.5.378
builder.SetMinMetadataSamplingInterval(1000);
// after: drop the call, or opt in deliberately
builder.SetMinSupportedSamplingInterval(1000);
Doing nothing is safe. MinSupportedSamplingInterval defaults to 0, which
reproduces 1.5.378 exactly: that release hard-coded
Server.ServerCapabilities.MinSupportedSampleRate to 0 and bounded the
revised sampling interval only by the MinimumSamplingInterval declared by the
monitored node. Setting a non-zero value raises the revisedSamplingInterval
for every monitored item except those on nodes declaring
MinimumSamplingIntervals.Continuous (0), which report by exception and are
not bound by a sampling interval. See
NodeManagers.md § Sampling interval revision
for the full rule.
Newtonsoft.Json removed from Opc.Ua.Core
Newtonsoft.Json is no longer a dependency of Opc.Ua.Core. Projects relying on its transitive availability must add an explicit reference:
<PackageReference Include="Newtonsoft.Json" Version="13.0.4" />
ParseExtension/UpdateExtension signature changed
ParseExtension<T>() and UpdateExtension<T>() now require T to implement IEncodeable. New delegate-based overloads were added for custom decoding:
// Generic overload (T must implement IEncodeable)
var config = configuration.ParseExtension<MyConfig>();
// Delegate overload for custom decoding
var config = configuration.ParseExtension<MyConfig>(
new XmlQualifiedName("MyConfig", myNamespace),
decoder => { var c = new MyConfig(); c.Decode(decoder); return c; });
ExtensionObject array helpers changed
ExtensionObject.ToArray(object, Type) and ToList<T>(object) removed. Use extensionObjects.GetStructuresOf<T>() or ExtensionObject.ToArray<T>(ArrayOf<ExtensionObject>).
IJsonEncodeable interface removed
The IJsonEncodeable interface and the entire "Default JSON Encoding" infrastructure have been removed. OPC UA JSON encoding is handled by the JsonEncoder/JsonDecoder classes which do not require per-type encoding node IDs — those classes are unaffected by this change.
Migration steps:
-
Remove
IJsonEncodeablefrom any custom class that implements it:- public class MyType : IEncodeable, IJsonEncodeable + public class MyType : IEncodeable -
Remove the
JsonEncodingIdproperty from those classes:- public ExpandedNodeId JsonEncodingId => ...;
Session and Browser State Persistence
Breaking Change: Persistence switched from DataContractSerializer XML to IEncoder and IDecoder. BrowserState, SessionState, SessionOptions, SubscriptionState, and MonitoredItemState are annotated with [DataType] and use the standard Encode/Decode methods generated by the source generator.
To register the state types with the encodeable factory:
context.Factory.Builder.AddOpcUaClientDataTypes();
The encoding format for session state has changed. Existing persisted session state files cannot be loaded by the new
SessionConfiguration.Create()method. Handle restore failures and re-persist the new session state.
See also
- Related: packages.md, certificates.md, identity.md.
- 2.0 migration index — analyzer quick-start + symptom → sub-doc table.
- Migration Guide — landing page across versions.