Developer command prompt for vs 2022 not initialized correctly when using wt command line

[brupelo]

Windows Terminal version

1.17.11461.0

Windows build number

Microsoft Windows [Version 10.0.19045.3208]

Other Software

No response

Steps to reproduce

Make sure you've got installed vs2022 and check that's working properly when using the dropdown menu

You should have available cl, ie: where cl

In order to check this bug open a new terminal with default "Command prompt" profile (no cl available in path) and run:

wt -w main new-tab -p "Developer Command Prompt for VS 2022" --startingDirectory c: --tabCommand cmd.exe dir

You'll see how a new window is created with the right title

but when i try to do where cl I'll get

where cl INFO: Could not find files for the given pattern(s).

Expected Behavior

I'd expect the profile being executed and configured properly in the new window

Actual Behavior

Profile hasn't been configured properly in the new window

[brupelo]

Just to let you know I've recently installed

Terminal (Portable) Version: 1.18.230526002-preview

and the issue still remains in that version

[237dmitry]

no cl available in path

where.exe searches only in the PATH.

[lhecker]

Without having further looked into it, I strongly suspect that when you write --tabCommand cmd.exe it breaks the profile. The VS 2022 profile doesn't just run cmd.exe as is after all, but rather:

cmd.exe /k "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\VsDevCmd.bat" -startdir=none -arch=x64 -host_arch=x64

In other words: Your issue will likely be fixed if you don't write --tabCommand cmd.exe.

[brupelo]

@lhecker You're right! I've tried wt -w main new-tab -p "Developer Command Prompt for VS 2022" --startingDirectory . and the profile is not breaking with this syntax.

A little bit more context, from SublimeText i'm able to invoke wt with different profiles and i was using --tabCommand in order to activate my current python virtual environment.

Here's an example of what I mean:

wt -w main new-tab -p "Developer Command Prompt for VS 2022" --startingDirectory C:\Users\Foo --tabCommand cmd.exe /K D:\sources\my_fancy_python_project\venv\Scripts\activate.bat

unfortunately, as you've explained... it seems that tabCommand will break the profile (although the virtualenv becomes activate). Is this a bug? If it's not, what'd be workaround to have both the profile enabled + virtualenv?

[lhecker]

It's funny that you ask this because this PR just happened to be submitted today: #15822. That would probably help you a lot with making this work. I would recommend subscribing to the corresponding issue #5528 for updates on when it gets released.

But the problem is that I'm not a Python dev and so I'm not sure how to make the VsDevCmd.bat + activate.bat combo work. If the above PR doesn't help you with that, I believe the alternative is for you to write your own "activate.bat" that invokes vswhere.exe to find a Visual Studio installation and then calls the VsDevCmd.bat in the installation directory (just like in my lengthy command above), followed by a call to activate.bat in your project.

In any case, I'll close the issue for now, because this doesn't appear to be a bug. But we can continue discussing it. Maybe someone comes along who has experience with this too... 🙂

[rofoto]

for anyone stumbling on this or similar errors when using the 'new' windows terminal in the future, you can replace the command in the settings for your version of the developer console with : '''%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\Tools\VsDevCmd.bat"'''

this command is just copy/pasted from the shortcut to launch the default Developer command prompt. copy this: and paste it here:

not sure why MS felt the need to use a different command to launch the same thing, but I am sure they had what they think is a good reason to do so. It just doesn't work.

[DHowett]

not sure why MS felt the need to use a different command to launch the same thing, but I am sure they had what they think is a good reason to do so. It just doesn't work.

This feature was contributed by somebody on the Visual Studio team.

At the end of the day, you are welcome to configure your profiles whatever way you see fit.