Open Pontation opened 1 week ago
The extension cannot know that that argument is mandatory. And if the extension manages command line arguments, you have to add "/rootsuffix Exp" in the command line arguments tree.
But the following would be nice for the extension:
Only manage the command line arguments for checked projects. That was what I initially expected, but an unchecked project means no arguments.
What does checked vs unchecked projects mean? Do you mean the current startup project as checked?
Take existing command line arguments specified in Visual Studio instead of wiping them.
Yeah this would make a lot of sense I think.
What does checked vs unchecked projects mean?
I meant in the extensions' tool window.
Take existing command line arguments specified in Visual Studio instead of wiping them.
This is actually the intended behavior. I havent used the extension in a long time and dont know the current state, however, afiak the extension should ask the user to init its json file from the project settings. Maybe the extension reads the project settings before adding the default command line for vsix projects?
Only manage the command line arguments for checked projects. That was what I initially expected, but an unchecked project means no arguments.
We expect that the user wants to use the extension when it is installed and open. Why would you want to disable the extension on a per-project basis?
Hi and sorry for my late response.
This should be kind of fixed with v3.0.3.1. There the extension is disabled until you enable it for the solution. When you enable it the extension should take the currently configured command line arguments of each project and add them to the tree.
It would be great if you could test this version a bit so I can finally release it. I had some issues with v3.0 which are hopefully fixed now but these problems never occurred when I was using the extension so it was difficult to test for me.
The versioning is currently a bit of a mess because I had to roll back v3.0 but the VS Market Place does not allow for a roll back, so I had to rerelease v2.6 as v3.1...
Why would you want to disable the extension on a per-project basis?
I have a mix of projects where for some I switch between local and remote debugging. VS keeps separate arguments for those. So ideally I'd have something like this extension which manages all debugger settings, not just command-line args. In the absence of that I'd use this extension only on those projects where I switch between sets of arguments and leave others alone.
When you create a new VSIXProject (Visual Studio Extension project) in VS2022, it comes pre-configured with the “/rootsuffix Exp” command line argument, which it uses to launch a new VS instance that comes preinstalled with the extension that you are debugging when you hit F5.
When Smart Command Line Arguments is enabled though, it will remove this command line argument which prevents the new VS instance from having this extension pre-installed, effectively meaning you can't debug it. Well maybe it's possible to build a VSIX package, install it and then attach to a running instance, but nobody wants to do that.
Reproduction steps Have Smart Command Line Arguments installed and enabled. Follow the steps under “Create a menu command” in this tutorial: https://learn.microsoft.com/en-us/visualstudio/extensibility/creating-an-extension-with-a-menu-command?view=vs-2022 At step 4 you should see that the extension does not appear in Extensions -> Manage Extensions
Note that just disabling Smart Command Line Arguments doesn't automatically make it work again. The user has to first put back "/rootsuffix Exp" as the command line argument, which they are probably not aware of since they did not add it manually themselves to begin with.
Initially I didn't know what was causing this issue, so I have a ticket here on the visual studio developer community in case you want to discuss the issue with visual studio peeps. https://developercommunity.visualstudio.com/t/New-extensions-dont-show-up-in-extensio/10787146
Thanks