Network resource \\wsl$\ is invalid according to .NET's System.Uri

[mast-eu]

I'm on Windows 10 version 1909 [build 10.0.18363.476] and have Ubuntu 18.04 running in WSL.

I've noticed that some Windows apps have issues when accessing Linux paths as network resource in the form of \\wsl$\Ubuntu-18.04\some\dir.
In my case, these apps are using the .NET API System.Uri to validate uniform resource identifiers (URI).

I made some tests and concluded the problem is very likely that \\wsl$\ is an invalid machine name:

• On one hand, \\wsl$\Ubuntu-18.04\some\dir is accessible as any normal directory, e.g. from the Windows Explorer.
• On the other hand, validation of \\wsl$\Ubuntu-18.04\some\dir with methods like System.Uri.TryCreate fails.
  Formally, this result seems to be correct to me, since \\wsl$\ is effectively an invalid name for network resources.

Here's a minimal example for reproduction with .NET Core 3.0:

using System;

namespace NetCoreApp
{
    class Program
    {
        static void Main()
        {
            string[] dirs = { "\\\\wsl$\\Ubuntu-18.04\\some\\dir", // WSL network resource (escaped)
                              "\\\\wsl\\Ubuntu-18.04\\some\\dir"}; // removed the dollar sign
            foreach (string dir in dirs)
            {
                Uri.TryCreate(dir, UriKind.RelativeOrAbsolute, out Uri uriCreated);
                if (uriCreated != null)
                    Console.WriteLine("Created URI: " + uriCreated + " from string " + dir);
                else
                    Console.WriteLine("Could not create an URI from string " + dir);
            }
        }
    }
}

The output is:

Could not create an URI from string \\wsl$\Ubuntu-18.04\some\dir
Created URI: file://wsl/Ubuntu-18.04/some/dir from string \\wsl\Ubuntu-18.04\some\dir

I am aware of #4308, which I think is describing the same issue.
However, the problem is not limited to Visual Studio, but probably affecting any .NET app using URIs.

[DHowett-MSFT]

This seems like a .NET issue, not a WSL issue.

[mast-eu]

As far as I know, a valid hostname may only contain letters a-z, numbers 0-9 and minus -. That's what .NET is checking for and I think it actually does the right thing, because it sticks to the relevant RFCs.

It's a WSL design decision to deliberately use an invalid hostname wsl$. Or at least that's what I understand from this blog post (in particular the Q&A at the end of the post) written by @craigloewen-msft.

In other words: WSL has opted for a non-standard hostname. This can create problems with any software working with hostnames and expecting strict standard conformity. This includes, but is not limited to, the .NET Framework itself as well as apps built on top of it.

[BLumia]

dotnet/runtime#36595 (comment) seems they are planning to change the hostname to something else which doesn't violates the spec.

[mast-eu]

According to the release notes, this has been fixed in build 20175:

- Change \\wsl$ prefix to \\wsl to support URI parsing. The old \\wsl$ path is still supported.