Allow null path segments when opening a DMS collection root #95

Problem

Opening DmsBrowser with an existing CenterDevice/Scopevisio collection as initialRootFolder and no preselected child folder fails during startup with:

System.NullReferenceException: Object reference not set to an instance of an object.
   at CompuMaster.Dms.Providers.BaseDmsProvider.CombinePath(String basePath, String[] paths)
   at CompuMaster.Dms.BrowserUI.DmsBrowser.BrowseDmsFolders_Load(...)

This was observed with CompuMaster.Dms 2026.10.10 through the Bierdeckel Management GUI.

Confirmed cause

DmsBrowser.BrowseDmsFolders_Load combines the configured initial root with SelectedFolder. SelectedFolder is legitimately Nothing when the caller wants to open the collection root without selecting a child folder.

BaseDmsProvider.CombinePath iterates over all supplied segments and calls StartsWith on each segment without accepting Nothing, which causes the exception before the provider can list the collection.

The collection exists and authentication is valid. It is also visible when the browser opens at the provider root; neither collection existence nor provider metadata is the cause.

Expected behavior

Null path segments represent an absent optional segment and must be ignored. Opening an existing collection root without a preselected child folder must succeed.

Proposed fix

• Make BaseDmsProvider.CombinePath ignore null path segments, including a null ParamArray.
• Document the null-segment behavior in the public XML documentation.
• Add provider-level regression coverage for null path segments.
• Add a DmsBrowser startup regression case with a non-empty initial root and selectedFolder = Nothing.
• Verify net48 and net8.0-windows.

Acceptance criteria

• CombinePath("Parent", Nothing) returns "Parent".
• Null elements between ordinary path segments are ignored.
• An existing CenterDevice/Scopevisio collection opens as initialRootFolder when no child folder is preselected.
• No unrelated exception is suppressed.

Final combined release checkpoint (2026-10-11)

This checkpoint supersedes prior pending integration/publication statements. The immutable changes from PR #94 were integrated with #95/#96 and the provider-independent root fix through merged PR #98 at main commit 97c897f172149a585776466fe85fa13f5a9de87f. The original #94 checkout was not changed; that PR was closed as superseded.

• Complete exact-main cumulative Level-2 CI: all three isolated OS jobs and all twelve serialized real-server jobs passed, covering Scopevisio Teamwork, generic WebDAV, ownCloud and Nextcloud on Windows/Linux/macOS.
• Inspect retained XML: 597 isolated provider cases passed on each OS; all 387 remote cases passed with no skips or failures. Windows GUI passed 411 cases with 20 declared optional native-monitor skips.
• Complete exact-main Level-2 native SDK-source validation, using isolated fake transport, separately from the remote matrix. External SDK package pins are unchanged.
• Publish DMS 2026.10.11.0 through the release-created workflow run 38161759973.
• Download and inspect both NuGet packages, their framework outputs and matching Providers dependency, plus all six binary/demo archives (including the Teamwork runtime dependency).
• Consume the published Providers/BrowserUI packages in an isolated external test program on .NET 8 and .NET Framework 4.8; verify null-path handling and compile/inspect the public failure event contract without GUI or server access.

Focused browser startup/diagnostics/root/scoped-collection fixtures passed 43 cases on net8.0-windows and the same 43 through a temporary linked-source net48 host. No full net48 GUI suite or new scoped-instance-switching scenario is claimed. Native large-transfer opt-in remains unchanged; no new 256 MiB/4 GiB live test is inferred. Broader RTL/DPI and consuming-application manual acceptance remain separate.

• Confirm the published fix in the affected Bierdeckel consuming application's manual acceptance; not performed by this package release.