Consider Uri .ctor to allow for paths starting with \\?\

[krwq]

See #58627 (comment) for context.

Would be nice if URI allowed for UNC paths such as i.e. those starting with \\?\ - that would make it easier to make long paths scenarios to work.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[karelz]

Triage: @krwq is there any reason, why Uri was used in these situation vs. Path?
We already regret we support path in Uri, extending it even more is not something we are thrilled about ...

[karelz]

@krwq ping?

[karelz]

Triage: Unclear what's customer demand, no info. Closing for now, we can reopen if there are customers asking for it.

[krwq]

@karelz legacy reasons, that's what full framework did in at least configuration manager and xml and there is still lots of legacy code relying on that

[karelz]

@krwq thanks for info. Given the arguments above and the fact we didn't hear from end customers about it yet since .NET Core 1.0, I am inclined to leave it closed for now and wait for feedback. If there is indeed strong demand from customers, we can change our mind in future.

[buyaa-n]

Another case reported Reading application settings in NET WinForms OOP designer fails with exception 'Invalid URI: The hostname could not be parsed" with similar root cause, but in this case we need to create Uri as it is used for subsequent calls:

runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs

Lines 251 to 269 in c8654e7

	Uri codeBase = new Uri(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, assembly.ManifestModule.Name));
	try
	{
	// Certain platforms may not have support for crypto
	hash = IdentityHelper.GetNormalizedStrongNameHash(assemblyName);
	}
	catch (PlatformNotSupportedException) { }
	if (hash != null)
	{
	typeName = StrongNameDesc;
	}
	else
	{
	try
	{
	// Certain platforms may not have support for crypto
	hash = IdentityHelper.GetNormalizedUriHash(codeBase);

@karelz could we reopen the issue and investigate?

[karelz]

We could consider it post-7.0 (as it is risky change), if there are scenarios where it is highly inconvenient to not use Uri -- is there more info on how it is being used and why Path might not work?

[buyaa-n]

In case if the hash was not populated from hash = IdentityHelper.GetNormalizedStrongNameHash(assemblyName) above, the Uri created here used for populating the hash by calling:

runtime/src/libraries/Common/src/System/Security/IdentityHelper.cs

Lines 31 to 36 in 6be8d27

	internal static string GetNormalizedUriHash(Uri uri)
	{
	// On .NET Framework System.Security.Url is used as evidence, it has an internal Normalize() method.
	// Uri.ToString() appears to be functionally equivalent.
	return GetStrongHashSuitableForObjectName(uri.ToString());
	}

the Uri is not looks essential in here and I could work around the bug but removing the \\?\ or something like that but I am not familiar with the code so not that sure what should be correct fix.

Anyway by seeing this kind of error reported again it feels like better to fix it at the root cause

[RussKie]

@karelz this bug affects Windows Forms out-of-process designer experience.

/cc: @merriemcgaw

[karelz]

@buyaa-n thanks for the info above. Can you please provide more details about how/where does the \\?\ path originates? Is there option to change that part to Path?

@RussKie understood from the context. Key questions I have: How does it work on .NET Framework? Is it a breaking change between .NET Core and .NET Framework?
Are there workaround options?

The key reason I am asking is that Uri is highly sensitive area. It is tricky code base with long history of MSRCs, and bad bugs. There were couple of design decisions in the past which lead to current state where paths are being treated as Uri, while behaving differently on Windows and Linux (often as a nasty surprise to users).
From that perspective, support for \\?\ is a feature, not a bug fix. And it would work only on Windows. It has non-trivial impact on the rest of the Uri and needs to be thought through very carefully.

Due to dev availability reasons, we won't be able to implement it before Platform complete, which also increases risk significantly. That's why I am looking strongly into alternatives in 7.0 time frame. And if we decide to do it, we need all the information we can get about the scenario.
Hope it helps to explain the context.

[buyaa-n]

Can you please provide more details about how/where does the \?\ path originates?

According to https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd \\?\ is added for long paths (260+plust characters)

The key reason I am asking is that Uri is highly sensitive area. It is tricky code base with long history of MSRCs, and bad bugs. There were couple of design decisions in the past which lead to current state where paths are being treated as Uri, while behaving differently on Windows and Linux (often as a nasty surprise to users).
From that perspective, support for \?\ is a feature, not a bug fix. And it would work only on Windows. It has non-trivial impact on the rest of the Uri and needs to be thought through very carefully.

Thanks for explanation, it seems Uri doesn't support \\?\ in .Net framework too, so seems its better to fix it in AppDomain.CurrentDomain.BaseDirectory there is open issue Consider stripping \?\ from AppDomain.CurrentDomain.BaseDirectory