Fix ConfigurationManager when BaseDirectory starts with \\?"

[krwq]

Fixes: #56897

Currently WinForms designer launches the process such that it prepends \\?\ because temporary directory it uses might end up with long path issues. This fixes the issue.

I did not find any scenarios where using Uri would have any benefits and Path.Combine seem to be fine to use.

Tested by creating a sample app which starts itself and prepends \\?\ to its own path and then executing ConfigurationManager.AppSettings.Get("foo") - in the success path it should return null, currently it throws an exception (only when process is launched with \\?\ prepended). Additionally tested the same when added App.config file with foo setting and made sure it read the value correctly.

Also tested by checking if Path.Combine correctly works for various paths (UNC, regular file path, \\?\ prepended path).

[ghost]

Tagging subscribers to this area: @safern
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #56897

Currently WinForms designed launches the process such that it prepends \\?\ because temporary directory it uses might end up with long path issues. This fixes the issue.

I did not find any scenarios where using Uri would have any benefits and Path.Combine seem to be fine to use.

Tested by creating a sample app which starts itself and prepends \\?\ to its own path and then executing ConfigurationManager.AppSettings.Get("foo") - in the success path it should return null, currently it throws an exception (only when process is launched with \\?\ prepended.

Also tested by checking if Path.Combine correctly works for various paths (UNC, regular file path, \\?\ prepended path).

Author:	krwq
Assignees:	-
Labels:	area-System.Configuration
Milestone:	-

[eerhardt]

Here's the original commit that added the call to new Uri: dotnet/corefx@3f0fff2. Originally (in .NET Framework) we were stripping the file:/// and file:// prefixes from the path. Do we still need to do that? I believe that's what the intention of the new Uri(...).LocalPath was doing. Or are we guaranteed that AppDomain.CurrentDomain.BaseDirectory will never have file:// prefixes?

Also, side question: is new Uri(...) supposed to be able to handle \\?? Would that be a "more complete" fix?

[jkotas]

Originally (in .NET Framework) we were stripping the file:/// and file:// prefixes from the path. Do we still need to do that?

It was necessary in .NET Framework because the code started with Assembly.CodeBase. Assembly.CodeBase is url (it can even be http://... in .NET Framework).

Or are we guaranteed that AppDomain.CurrentDomain.BaseDirectory will never have file:// prefixes?

Yes. BaseDirectory is always file path, no file:// prefix.

Also, side question: is new Uri(...) supposed to be able to handle \?? Would that be a "more complete" fix?

Maybe. Uri parsing is very complex with many legacy quirks and any fixes in it are risky and involved. Not a good candidate for .NET 6 fix.

Also, we may want to strip \\? from the BaseDirectory. I believe that our general approach is to avoid leaking \\? to user code where possible.

It may be a good idea to create a follow up issues for both of these.

[eerhardt]

Given @jkotas's answers above, this LGTM.

It may be a good idea to create a follow up issues for both of these.

+1

[krwq]

Thanks @jkotas and @eerhardt!