Enable setting the VS dev environment without running from Dev Command Prompt

[bobbrow]

This change removes the requirement of running VS Code from a Developer Command Prompt in order to build with the Visual Studio C++ compiler on Windows.

Two commands are added:

• Set Visual Studio Developer Environment - Starts the process of picking the MSVC toolset that will be used to compile. This environment will be added to any new terminals launched from this session of VS Code. It will also be automatically applied for the Build and Debug feature. Note that the environment changes only apply to the current workspace. The command will need to be run on every workspace that needs the environment.
• Clear Visual Studio Developer Environment - Removes the MSVC toolset environment.

One setting is added:

• C_Cpp.persistDevEnvironment - This controls whether the developer environment is automatically applied the next time the workspace is opened.

Walkthrough updates

The walkthrough is updated with a button to run the command and the instructions include the command as an alternative option to running VS Code from the Developer Command Prompt:

Play button updates

The Play button for Build and Debug Active File incorporates this command in the workflow if the developer environment is not detected. This should make the experience seamless going forward.

Terminal updates

When the command is run, any existing terminals will show a message prompting you to relaunch them so that the environment will apply to them.

Telemetry

Telemetry is added to track where the command was invoked.

[sean-mcmanus]

Can this be fixed?

[sean-mcmanus]

I think it should just silently cancel instead of showing an error.

I think an error might be okay if it was an actual error occurrence (and without it the user may not know it failed) but not a user cancellation though (via not selecting an option in the dropdowns).

We don't share an error popup in other cancellation cases.

Same as when the user hits the "Cancel" button:

[sean-mcmanus]

Can you add the command name?

It's possible the command may not have been invoked from the developer command prompt or in a way the user is 100% sure what command is run, such as via a keyboard shortcut.

Umm...unless VS Code itself is showing that message, I haven't checked yet.

[sean-mcmanus]

Can we align the setting name more with CMake Tools?

i.e. C_Cpp.persistVsDeveloperEnvironment ?

i.e. "VsDeveloper" seems preferable to "Dev" since it's more explicit that it applies to Visual Studio. And "Dev" seems informal for a setting name.

[bobbrow]

Can this be fixed?

[image]

Yes, I think it should have the "Preview" part of the installation name, but it's missing.

#resolved

[bobbrow]

Can we align the setting name more with CMake Tools?

[image]

i.e. C_Cpp.persistVsDeveloperEnvironment ?

i.e. "VsDeveloper" seems preferable to "Dev" since it's more explicit that it applies to Visual Studio. And "Dev" seems informal for a setting name.

Sure. I don't feel very strongly about it. I was just trying to keep it short.

#resolved

[bobbrow]

Can you add the command name?

[image]

It's possible the command may not have been invoked from the developer command prompt or in a way the user is 100% sure what command is run, such as via a keyboard shortcut.

Umm...unless VS Code itself is showing that message, I haven't checked yet.

Yes, I can add the command name. This is our message. The command shouldn't be visible in the Command Palette on linux/mac though. If you are seeing it there, please tell me there is a bug.

#resolved

[bobbrow]

I think it should just silently cancel instead of showing an error.

[image]

I think an error might be okay if it was an actual error occurrence (and without it the user may not know it failed) but not a user cancellation though (via not selecting an option in the dropdowns).

We don't share an error popup in other cancellation cases.

Same as when the user hits the "Cancel" button:

[image]

I agree that we don't need to show it for Cancel. I will think about the other scenario some more.

#resolved

[sean-mcmanus]

Did you make sure you copied over the debugAdapters folder in your local version of the extension? It's something I forgot to do when I started testing this and it confused me for a bit.

Yeah, I was on a new machine -- copying over the 1.25.3 vsix contents fixed it.

[sean-mcmanus]

• In the Debug Open File scenario, I seem to get no dropdown to choose which VS environment to use. Is that a "by design" limitation of not having a folder open? Debugging seems to work somehow, but it shows no popup with the Apply Developer Environment option.

UPDATE: Oops, I think it was because I had previous did the Apply (last week) in the no open folder scenario -- that's "by design", right? I get the Apply option again after I do a Clear.

[bobbrow] Yes, you may also have to close any left over terminals from the previous devenv state before trying future commands too.

[sean-mcmanus]

• Is it supposed to show the error "The Visual Studio Developer Environment was not applied. Please try again or run VS Code from the Developer Command Prompt for VS." after using the Debug button twice without clicking an option in the Apply Developer Environment popup? It seems unexpected, i.e. it doesn't make sense to tell the user that the dev environment wasn't applied when they never clicked a button to apply it in the first place.

[bobbrow] Interesting bug, I believe I have a fix for this.

[sean-mcmanus]

• I still see the error "The Visual Studio Developer Environment was not applied. Please try again or run VS Code from the Developer Command Prompt for VS." when I hit the X/Close button in the top right of the apply dialog, but it doesn't appear when I hit the Cancel button. It seems like it shouldn't show when the user hits the X button since it's pretty obvious that it wasn't applied.

[bobbrow] I have a fix for this

[sean-mcmanus]

• When the dropdown appears to select an environment, I get no "The Visual Studio Developer Environment was not applied. Please try again or run VS Code from the Developer Command Prompt for VS." when I use the Set command, but I get that error when I click the button (which is inconsistent). I think in both cases the error message should not appear since it should normally be obvious that a quick pick option was not clicked, therefore not applied. Even if there is confusion in some rare case, the user will get the Apply option when it fails the 2nd time, so it doesn't seem necessary to explicitly tell the user the environment was not set -- except potentially if there was some unexpected failure condition after the user actually did click the options.

[bobbrow] My thought process is this:

• In your first case (run the "Set VS Developer Environment" command), no message is provided because the command is the primary action and it was clear that you cancelled it by dismissing the drop down.
• In your second case (click the debug button which spawns the Apply button), a message is provided because the primary command (BuildAndDebug) can no longer continue due to a secondary operation (SetVSDevEnvironment) which took the focus but ended up being cancelled. I am changing the message to tie the consequence of the second action back to the primary action thus restoring the context back to that action.
  • I will be keeping a message for this scenario. I welcome any feedback on the message provided.

Resolution: Reworded the error message.

[sean-mcmanus]

• It doesn't work if you run the Configure Default Build Task (or any steps to create a tasks.json) and then press the F5 button or the "Run and Debug" side panel button (no Apply Dev Env option appears):
  

  Alternate repro step are to do the Apply (generates the tasks.json), then do the Clear, and then do F5.

  The Apply popup appears with F5 if no tasks.json exists.

[bobbrow] Good bug. It uncovered another issue too. I fixed them both.

[bobbrow]

I'm going to put checkboxes and responses in your messages directly, since it's somewhat difficult to track these issues outside of comments directly in the code. I hope that's ok.

[sean-mcmanus]

I'm going to put checkboxes and responses in your messages directly, since it's somewhat difficult to track these issues outside of comments directly in the code. I hope that's ok.

Sure, you had mentioned making a comment in the code, but I wasn't referring to any particular code. I'm not sure why GitHub doesn't have a UI that allows a reply thread that is easy to use.

[sean-mcmanus]

• I get no option to select the debugger type of GDB when I do F5 with no folder open. It works in 1.25.2. Using the Clear option doesn't fix it. I repro the same issue with a workspace folder open too, but you have to make sure no tasks.json/launch.son exists. Oh, the repro might require certain conditions. I don't understand why I sometimes repro it and other times I don't. UPDATE: Okay, it seems like there might be some persistent state being saved even after the Clear is used (and after a reload window). It stopped reproing when I switched from VS Code Insiders to non-Insiders, but after I ran the Apply and then Clear, it started reproing for non-Insiders.

[bobbrow] I'll mark this as resolved since it doesn't sound like it's related to my change.

But it seems to only start reproing after I apply the developer environment one time? Also, I try 1.25.2 and the bug doesn't repro, but it starts to repro when I use your branch. Oh, I repro it with main too...

UPDATE: Yeah, it seems like a bug with VS Code itself. I can't figure out how to change the debugger type after I select one for a workspace folder.

[bobbrow]

Hmm, it seems my rebase did not go as planned. Please wait before reviewing any changes.

[bobbrow]

This is ready for review now.