Request for Updated VisualStudio.Extensibility Extension Publishing Guidelines and Improvements to GetSelectedPathAsync Method Behavior

[ynanech]

While developing an extension with VisualStudio.Extensibility, I've encountered several issues.

Firstly, regarding the release process of extensions, I couldn't find any up-to-date official documentation or guidelines. The resources I found (like the link #233) seem outdated.

Secondly, when using the await context.GetSelectedPathAsync(cancellationToken) method, I noticed that it throws an exception if no path is selected by the user, instead of returning a nullable URI. Moreover, when the method returns a URI, it should preserve the original case of the path rather than converting everything to lowercase.

[tinaschrepfer]

@ynanech - publishing a VisualStudio.Extensibility extension is the same as publishing a VSSDK one. You can find the documentation here: https://learn.microsoft.com/en-us/visualstudio/extensibility/walkthrough-publishing-a-visual-studio-extension?view=vs-2022

Regarding your other questions, throwing an exception when no path is selected does seem unexpected. I'll follow up with the team to see if it's a bug.

As to why we're always normalizing the URI to be lowercase, can you tell us why you'd prefer the casing to be preserved? We normalize since there are intermediate services that use the the URI as a key or moniker. If there's a valid scenario where casing should be preserved, we'd love to know so we can discuss whether how this can be supported.

[ynanech]

@tinaschrepfer thank you . URI retains the original character case, and I mainly use it for obtaining the original file name in the currently selected path.

[zivkan]

@tinaschrepfer regarding normalizing filesystem URIs has two potential problems, but only if the extension persists the file URI somewhere:

1. Turkish I problem
   The Turkish language has dotless and dotted i letters. So, a team member not using tr-tr as their locale will have `"I".ToLower()" result in a different character to another team member who is using tr-tr as their locale. If the filename gets persisted, then there will probably be file not found exceptions trying to open the file.

2. Linux
   Again, if the extension persists the file URI to the project (or any other file), which is later needed as part of the build, the file won't be found on a Linux host. Technically it's possible to use fsutil.exe on a Windows machine to configure an NTFS drive to be case sensitive as well. In which case this API will result in a file path that can't be opened.

Unfortunately, Windows doesn't appear to have an API to get the canonical name for a file. All the suggestions I can find online involve getting the directory listing of every directory in the path, and then finding the match to find the canonical directory or file name.

Therefore, I suggest not normalizing the path at all. Use the path as provided by MSBuild. That way if the project file includes a file via a glob (for example **/*.cs), MSBuild is responsible for providing the file's canonical name. If the customer hand-edits the project file, it's their responsibility to use the correct casing if building on Linux fails.

My feedback doesn't apply if you're absolutely certain that VS extension developers will not persist the filename either to the project file, or any other file, which will later be read and then used to open a file.

Finally, I recommend against the use of System.Uri at all, but especially for file names. Unfortunately, since this API already shipped using Uri, it would be a breaking change to modify. The problem with Uri as a data type is that it causes a lot of memory allocations, since it has APIs that split the URI into different segments, and the URI scheme as a different property, the hostname, etc. It does all these memory allocations on construction, not on first use of properties that read those properties. I'm sure the VS Perf team could provide more information as well.