Fixes an issue in Session.LoadDataTypeSystem.

[AndreasHeisel]

Proposed changes

Starting with line 1857 a dictionary of namespaces is populated in an defensive manner. If a namespace value can't be read, it is silently ignored. If this happens, it will result in a KeyNotFoundException when populating the imports dictionary. This fix adds a warning if a namespace value can't be read and populates the imports dictionary also defensivly.

Related Issues

• Fixes #

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply. You can also fill these out after creating the PR.

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc.
• I have signed the CLA.
• I ran tests locally with my changes, all passed.
• I fixed all failing tests in the CI pipelines.
• I fixed all introduced issues with CodeQL and LGTM.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

Further comments

We noticed the problem when communicating with a server that hat a namespace value wich was not of type string.

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

Merging #2166 (67553aa) into master (5f54e08) will decrease coverage by 2.05%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master    #2166      +/-   ##
==========================================
- Coverage   57.90%   55.85%   -2.05%     
==========================================
  Files         324      306      -18     
  Lines       61826    59234    -2592     
==========================================
- Hits        35801    33086    -2715     
- Misses      26025    26148     +123     

Impacted Files	Coverage Δ
Libraries/Opc.Ua.Client/Session.cs	66.42% <66.66%> (-0.36%)	⬇️

... and 78 files with indirect coverage changes

[AndreasHeisel]

Good morning,

I need help fixing the failed test 'Build and Test .NET 6.0 / test-macOS-latest-Client.ComplexTypes (pull_request) ':
It claims, the build failed. But if I look at the logs I only see

The build itself seems to work...

Thank you

[mregen]

probably flaky build...

[AndreasHeisel]

Thank you

There is one issue open, code coverage.

I have no idea how to write a unit test to test this. Looking at the coverage I see that error-pathes are often not covered ...

[mregen]

Thanks, code coverage is sometimes also flaky and not blocking...

[AndreasHeisel]

Ok, so am I ready? - it's my first PR in this repo

one last question: Should I do the same for the 1.5 branch or is there some internal process for this?

[mregen]

Hi @AndreasHeisel , thanks for the fix! The 1.5 branch is only updated from time to time until it could be certified it remains in beta state.