Extensions written in C# fail when opening files from remote repo and a non-default branch

[StephenWeatherford]

I've now seen this in two of our extensions:

Azure/bicep#11467
microsoft/vscode-azurearmtools#1647

Hard to believe no one else has seen this.
To repro:
Follow steps here: Azure/bicep#11467 (comment)

My investigation results are here: Azure/bicep#11467 (comment)

The problem is that for non-default branches, the URI we get for the document looks like this:

vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a225374657068656e57656174686572666f72642d70617463682d31227d7d/StephenWeatherford/template-examples/bicep/templatespec/client.bicep

This appears to technically be a valid URI, but OmniSharp (language server framework) and C#'s own System.Uri do not seem to handle it.

Example: System.Uri failing (whether the "+" is encoded or not):
new System.Uri("vscode-vfs://github+7b2276223a312c22726566223a7b2274797065223a342c226964223a225374657068656e57656174686572666f72642d70617463682d31227d7d/StephenWeatherford/template-examples/bicep/templatespec/client.bicep", System.UriKind.Absolute)
'new System.Uri("vscode-vfs://github+7b2276223a312c22726566223a7b2274797065223a342c226964223a225374657068656e57656174686572666f72642d70617463682d31227d7d/StephenWeatherford/template-examples/bicep/templatespec/client.bicep", System.UriKind.Absolute)' threw an exception of type 'System.UriFormatException'

System.Uri.IsWellFormedUriString() returns false.

By contrast, on the default branch the URI has this format:
github://github/StephenWeatherford/template-examples/bicep/main.bicep

[StephenWeatherford]

Can you please provide guidance? We need to be able to parse the URIs for documents. Thanks.

[joyceerhl]

Thanks for investigating. These are valid VS Code URIs based on our current validation logic which aims to match http://tools.ietf.org/html/rfc3986. The authority encodes information about the branch, so if you stripped out that data you would end up reading the contents of the main branch. We also use + in vscode-remote URI authorities. It's very unlikely that we'd be able to change this URI structure in Remote Repositories since it could cause data loss for uncommitted changes that are stored per-URI. IMHO as you've suggested dotnet/runtime#64707 is the upstream issue.

[StephenWeatherford]

Understood, but that still leaves us and who knows how many other language servers vulnerable if we can't parse your URIs? Do you want us to disable our extension being loaded when it's not loaded locally? It looks like that might be what C# did, but feels like it kind of defeats the purpose of your extension?

[joyceerhl]

While your extension is unable to handle these URIs with the .NET runtime's curent URI parsing implementation, it might be preferable to temporarily declare that your extension can't support virtual workspaces. You can do this in the package.json manifest with "virtualWorkspaces": false. Also cc @alexdima in case there is additional guidance on URIs that we can share.

[StephenWeatherford]

We have disabled virtual workspaces.