search

dotnet / command-line-api

Command line parsing, invocation, and rendering of terminal output.
https://github.com/dotnet/command-line-api/wiki
MIT License
3.37k stars 378 forks source link

dotnet-suggest doesn't work for Microsoft Store Apps #2074

Open azchohfi opened 1 year ago

azchohfi commented 1 year ago

The Microsoft Store Developer CLI (https://github.com/microsoft/msstore-cli) is built using System.CommandLine.

We've enabled suggestions, but the registration process is using this exe's path at the .dotnet-suggest-registration.txt file: C:\Program Files\WindowsApps\Microsoft.MicrosoftStoreCLI_0.1.20.0_x64__8wekyb3d8bbwe\msstore.exe which is the real exe file linked by the 0 byte file that acts as a "shortcut" to the actual executable. This "shortcut" lives here: C:\Users\{USER}\AppData\Local\Microsoft\WindowsApps\MSStore.exe

Running: dotnet-suggest get -e "C:\Users\{USER}\AppData\Local\Microsoft\WindowsApps\MSStore.exe" returns nothing, but running: dotnet-suggest get -e "C:\Program Files\WindowsApps\Microsoft.MicrosoftStoreCLI_0.1.20.0_x64__8wekyb3d8bbwe\MSStore.exe" returns the actual suggestions.

The problem seems to be that the registration is using the real assembly (which is not wrong), but the Register-ArgumentCompleter script block is using Get-Command, which returns the 0 byte file, which is not registered.

azchohfi commented 1 year ago

This might help: https://stackoverflow.com/questions/62474046/how-do-i-find-the-target-of-a-windows-app-execution-alias-in-c-win32-api

azchohfi commented 1 year ago

This is fixed by running: dotnet-suggest register --command-path C:\Users\{USER}\AppData\Local\Microsoft\WindowsApps\MSStore.exe, but ideally this should not be required.

azchohfi commented 1 year ago

This is our manifest section that adds the "link", which might also help in the resolution of this issue: https://github.com/microsoft/msstore-cli/blob/f274b7a6ddb0f9141ad0a1f0e3905bc1cc17d4f3/MSStore.CLI.MSIX/Package.Store.appxmanifest#L43-L48

Ideally, the RegisterWithDotnetSuggest method should have a net6.0-windows10.0.17763.0 tfm version that retrieves the right info from the manifest, properly supporting this case and automatically doing the proper registrations, or at least the RegisterWithDotnetSuggest method should have an overload that allows developers to pass a callback that returns both the command path and suggestion command that are passed to dotnet-sugget's register command (ideally a list of this tuple).

KalleOlaviNiemitalo commented 1 year ago

The REPARSE_DATA_BUFFER_APPEXECLINK parsing feature was removed from PowerShell in https://github.com/PowerShell/PowerShell/pull/16044 because the AppX team did not want applications to rely on the structure. Is there now a supported way to retrieve information about the link?

(It might be best if support for dotnet-suggest could be declared in the appx manifest itself, perhaps via "windows.appExtension".)

KalleOlaviNiemitalo commented 1 year ago

Related issues about registering for dotnet-suggest: