starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Visual Studio Generator should probably prefer x64 tools when available #15322

New Issue
Closed
opened 2026-01-31 04:35:04 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 04:35:04 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (Sep 22, 2021).

From #7774

Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls vcvars64.bat. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :)

@kasper93 That's a good point! VS features 6 items in the start menu:
image

Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls vcvars64.bat. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :)

Let's file a new issue at this point to represent adding preferences to the profile generator like which architecture is prioritized. Thanks!

So, the way I found to do it is to edit the profile generated by this generator and add -DevCmdArguments "-arch=x64 -host_arch=x64" or something to the Enter-VsDevShell arguments, or add -arch ... directly to the vsdevcmd.cmd arguments.

<discuss>

Originally created by @zadjii-msft on GitHub (Sep 22, 2021). From #7774 > Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls `vcvars64.bat`. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :) > @kasper93 That's a good point! VS features 6 items in the start menu: > ![image](https://user-images.githubusercontent.com/2256941/134418224-a5ad0ee7-3a4f-4958-b1d9-e7d975f4c948.png) > > Sorry to bring back closed PR to life, but is there a way to setup it to run x64 prompt by default? I still have my custom profile which calls `vcvars64.bat`. It is nice addition, but well unless you want to build 32-bit binaries it is kind of useless :) > > Let's file a new issue at this point to represent adding preferences to the profile generator like which architecture is prioritized. Thanks! > So, the way I found to do it is to edit the profile generated by this generator and add `-DevCmdArguments "-arch=x64 -host_arch=x64"` or something to the Enter-VsDevShell arguments, or add `-arch ...` directly to the `vsdevcmd.cmd` arguments. \<discuss>
claunia added the Resolution-Fix-CommittedArea-SettingsIssue-TaskProduct-Terminal labels 2026-01-31 04:35:05 +00:00
claunia commented 2026-01-31 04:35:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 22, 2021):

IMO adding 6 profiles per install vs 2 profiles per install seems a little heavy, and way more likely that I'm just gonna delete them all.

I'm gonna also summon @trippwill (as OP of the PR) and @heaths (as the literal vswhere expert) to this thread for discussion

@zadjii-msft commented on GitHub (Sep 22, 2021): IMO adding 6 profiles per install vs 2 profiles per install seems a little heavy, and way more likely that I'm just gonna delete them _all_. I'm gonna also summon @trippwill (as OP of the PR) and @heaths (as the literal vswhere expert) to this thread for discussion
claunia commented 2026-01-31 04:35:07 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 23, 2021):

I, too, was initial concerned about "too many" profiles but it's not hard to hide them. While I mostly agree with only showing x64 shells by default (when there are both), all those shells are designed for specific workloads where users may prefer one over another - even for different tasks.

As more and more possibilities are added (consider numerous WSL2 distros installed), what about some sort of grouping mechanism in WT? Discovery could attach some "group attribute" so they are put into a submenu together. In the case of VS, I'd recommend doing that per-version e.g. VS2019 vs. VS2022. Though, in that case, I imagine you'd need to make keyboard bindings explicit instead of purely-indexed based (or maybe that's possible now already).

@heaths commented on GitHub (Sep 23, 2021): I, too, was initial concerned about "too many" profiles but it's not hard to hide them. While I mostly agree with only showing x64 shells by default (when there are both), all those shells are designed for specific workloads where users may prefer one over another - even for different tasks. As more and more possibilities are added (consider numerous WSL2 distros installed), what about some sort of grouping mechanism in WT? Discovery could attach some "group attribute" so they are put into a submenu together. In the case of VS, I'd recommend doing that per-version e.g. VS2019 vs. VS2022. Though, in that case, I imagine you'd need to make keyboard bindings explicit instead of purely-indexed based (or maybe that's possible now already).
claunia commented 2026-01-31 04:35:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 23, 2021):

We've actually got a big-ol design for profile grouping in #1571 (there's a spec for that here:https://github.com/microsoft/terminal/blob/main/doc/specs/%231571%20-%20New%20Tab%20Menu%20Customization/%231571%20-%20New%20Tab%20Menu%20Customization.md). The original design was entirely outside of the list of profiles though. It simply provides a way for users to separately group their profiles, rather than allowing dynamic profile generators the ability to say "please group my profiles together".

Though, if I remember the discussion correctly, we did think it would be a cool idea for people to easily say "please put all the WSLs in this nested list". Maybe we should bump that spec with an addenda for something like "remainingProfiles but for a profile source"

@zadjii-msft commented on GitHub (Sep 23, 2021): We've actually got a big-ol design for profile grouping in #1571 (there's a spec for that here:https://github.com/microsoft/terminal/blob/main/doc/specs/%231571%20-%20New%20Tab%20Menu%20Customization/%231571%20-%20New%20Tab%20Menu%20Customization.md). The original design was entirely outside of the list of profiles though. It simply provides a way for users to separately group their profiles, rather than allowing dynamic profile generators the ability to say "please group my profiles together". Though, if I remember the discussion correctly, we did think it would be a cool idea for people to easily say "please put all the WSLs in this nested list". Maybe we should bump that spec with an addenda for something like "`remainingProfiles` but for a profile source"
claunia commented 2026-01-31 04:35:08 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 23, 2021):

something like "remainingProfiles but for a profile source"

Sounds like a good idea and is congruent with the concept I was thinking. Presumably people could still move profiles to another menu based on their stable guid property.

My main concern here is that deciding for the user what's relevant won't work for all users. Maybe in the meantime we can set "hidden": true by default for some of them e.g. x86 if x64 is available but still generate them.

@heaths commented on GitHub (Sep 23, 2021): > something like "remainingProfiles but for a profile source" Sounds like a good idea and is congruent with the concept I was thinking. Presumably people could still move profiles to another menu based on their stable `guid` property. My main concern here is that deciding for the user what's relevant won't work for all users. Maybe in the meantime we can set `"hidden": true` by default for some of them e.g. x86 if x64 is available but still generate them.
claunia commented 2026-01-31 04:35:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 23, 2021):

Maybe in the meantime we can set "hidden": true by default for some of them e.g. x86 if x64 is available but still generate them.

ryan-point

@zadjii-msft commented on GitHub (Sep 23, 2021): > Maybe in the meantime we can set `"hidden": true` by default for some of them e.g. x86 if x64 is available but still generate them. ![ryan-point](https://user-images.githubusercontent.com/18356694/134559211-c6fd24ab-4949-43c4-9ec0-6899ea88c729.gif)
claunia commented 2026-01-31 04:35:08 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 23, 2021):

...and without nesting, one could also prioritize showing newer versions - even prereleases - over older versions. If we're only considering hiding other entries by default to clean them up (until WT supports nesting menus), then I see no harm in showing preferred entries, which one could assume that most users would prefer the latest version of what they installed, and the shell that supports the most targets and/or faster tools e.g. x64.

vswhere works similarly with the -latest flag, which is what many build pipelines use from what I've seen. This, in concept, would be similar to adding -prerelease which, for dev shells, I think makes sense. CIs and especially release pipelines might normally only want to stick with stable releases, but I doubt that's true for most devs who chose to install a prerelease.

@heaths commented on GitHub (Sep 23, 2021): ...and without nesting, one could also prioritize showing newer versions - even prereleases - over older versions. If we're only considering hiding other entries by default to clean them up (until WT supports nesting menus), then I see no harm in showing preferred entries, which one could assume that *most* users would prefer the latest version of what they installed, and the shell that supports the most targets and/or faster tools e.g. x64. vswhere works similarly with the `-latest` flag, which is what many build pipelines use from what I've seen. This, in concept, would be similar to adding `-prerelease` which, for dev shells, I think makes sense. CIs and especially release pipelines might normally only want to stick with stable releases, but I doubt that's true for most devs who *chose* to install a prerelease.
claunia commented 2026-01-31 04:35:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 23, 2021):

FWIW, the PowerShell Core generator does a similar thing where it prefers newer versions of pwsh.exe over older ones.

@zadjii-msft commented on GitHub (Sep 23, 2021): FWIW, the PowerShell Core generator does a similar thing where it prefers newer versions of pwsh.exe over older ones.
claunia commented 2026-01-31 04:35:09 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 24, 2021):

I'll take a stab at this with the idea of hiding some/most by default.

@heaths commented on GitHub (Sep 24, 2021): I'll take a stab at this with the idea of hiding some/most by default.
claunia commented 2026-01-31 04:35:09 +00:00
Author
Owner
Copy Link

@kasper93 commented on GitHub (Sep 25, 2021):

My main concern here is that deciding for the user what's relevant won't work for all users. Maybe in the meantime we can set "hidden": true by default for some of them e.g. x86 if x64 is available but still generate them.

Indeed I agree that polluting profile list with multiple profiles is not great and deciding for the user which ones to show/hide might not be possible reliably.

How about we provide automatic profile generation, but in fact hide them all by default? And let users enable easily whatever they need.

I'm kind of referring also to the #11326 PR. Well I have both VS2019 and VS2022 installed, but use mainly VS2019 so yeah, right of the gates I would need to switch it up.

Long story short I appreciate automatic generation of profiles (and future generation for each arch) it makes life easier to not do it manually. But those profiles should be imho opt-in whenever user wants to show them or not.

@kasper93 commented on GitHub (Sep 25, 2021): > My main concern here is that deciding for the user what's relevant won't work for all users. Maybe in the meantime we can set `"hidden": true` by default for some of them e.g. x86 if x64 is available but still generate them. Indeed I agree that polluting profile list with multiple profiles is not great and deciding for the user which ones to show/hide might not be possible reliably. How about we provide automatic profile generation, but in fact hide them all by default? And let users enable easily whatever they need. I'm kind of referring also to the #11326 PR. Well I have both VS2019 and VS2022 installed, but use mainly VS2019 so yeah, right of the gates I would need to switch it up. Long story short I appreciate automatic generation of profiles (and future generation for each arch) it makes life easier to not do it manually. But those profiles should be imho opt-in whenever user wants to show them or not.
claunia commented 2026-01-31 04:35:09 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (Sep 26, 2021):

Based on telemetry, the vast majority of users only have a single version of VS installed, and the assumption is that most would want to use their newest installed version by default (they are also capable of targeting older versions in most cases). Why not provide the best experience automatically for the majority of users?

The PR shows the latest version of VS, and if VC is installed only shows the matching processor architecture by default. You can still toggle visibility on any discovered profiles.

@heaths commented on GitHub (Sep 26, 2021): Based on telemetry, the vast majority of users only have a single version of VS installed, and the assumption is that most would want to use their newest installed version by default (they are also capable of targeting older versions in most cases). Why not provide the best experience automatically for the majority of users? The PR shows the latest version of VS, and if VC is installed only shows the matching processor architecture by default. You can still toggle visibility on any discovered profiles.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Issue-Task Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15322
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?