vscode-cpptools
vscode-cpptools copied to clipboard
microsoft
Enable setting the VS dev environment without running from Dev Command Prompt
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.
After setting the dev environment (with a folder open), I can't debug with cl.exe. It just builds but debugging never starts.
It seems to just run "C/C++: cl.exe build active file" and the "debug" part is not run.
i.e. the walkthrough steps aren't working for me.
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.
#resolved
Can this be fixed?
[image]
Yes, I think it should have the "Preview" part of the installation name, but it's missing.
#resolved
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
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
FYI, it was able to set the developer environment when I didn't have a workspace open. Not sure what effect that has.
[image]
This feature adds to the environment variables, so if you open a new terminal in a no-workspace window, you should see the VS devenv applied there.
#resolved
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
Did you make sure you copied over the
debugAdaptersfolder 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.
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.
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.
If VS Code is already launched from a particular VS developer command prompt, then the Set VS Developer Environment command is still available and runnable, but confusingly has no effect with no warning that it's not actually used, i.e. it just uses the original environment. Can that be fixed somehow or give a warning? Or is it supposed to work and switch to the newly selected developer environment?
I would expect it to override the inherited environment. Does it not work for you? It worked for me.
I would expect it to override the inherited environment. Does it not work for you? It worked for me.
It doesn't override the inherited environment (for me). I confirm that via running cl.exe --version with the restarted terminal. How are you confirming that?
Yeah, I've double checked and I repro it -- it seems the Set environment can change the arm/x86/x64 target but the version of the compiler is not switched when it should be. The version does change if VS Code is not launched from a developer command prompt.
Here's a screenshot -- the Int Preview environment is selected but the Enterprise environment is used instead, i.e. it's not using 19.44.35128. This is after reloading the terminal with the new environment.
Running command Terminal: Show Environment Contributions shows the bug too (the Enterprise path should be Preview):
The only environment variables that I see update are these:
The PATH modification is the addition of C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\Tools, however that is insufficient to change the cl.exe that is used since cl.exe is not at that path.
UPDATE: Yeah, running the Set Vs Environment is not setting all the expected environment variables if VS Code is launched from the developer command prompt -- it appears to put the environment into an invalid state that is missing most of the environment expected environment variables:
The green shows the environment variables that become removed when the Set Vs Environment is run (excluding the 3 environment variables shown in the previous screenshot).
Ok, I did notice an oddity that I will need to debug. Something wrong did happen when the dev environment is already set and it does appear to fail to update all of the required variables.
I originally only checked that the compiler was coming from the correct path, but you are right that the environment is not correct. (e.g. VSINSTALLDIR is wrong in that screenshot)
I have a fix for the "run from the developer command prompt" scenario in the node module. I just need to wait for it to show up in CFS so I can consume it.
https://github.com/bobbrow/node-vcvarsall/commit/5556a2851d1ae968302b2da65b7b54431560bb39
The Apply Developer Environment popup doesn't appear if the VS install for the persisted environment is changed (removed or the version changes). It just fails to find the cl.exe.
[image] It seems like user could be confused why it stopped working and they may not know they need to run the Clear/Set again. Are we able to detect that condition and do the Clear ourselves?
Are you talking about when you upgrade VS and get a new toolset version for cl.exe? We can probably check for that.
Are you talking about when you upgrade VS and get a new toolset version for cl.exe? We can probably check for that.
Yes upgrade or uninstall, e.g. uninstall Preview but you have non-Preview still then ideally the Apply option would appear for the non-Preview that is still installed.
~~Hmm, it seems my rebase did not go as planned. Please wait before reviewing any changes.~~
This is ready for review now.
@bobbrow Oh, sorry, I didn't notice your comment for some reason.