Visual Studio Generator should probably prefer x64 tools when available

[zadjii-msft]

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:

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>

[zadjii-msft]

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

[heaths]

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).

[zadjii-msft]

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"

[heaths]

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.

[zadjii-msft]

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]

...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.

[zadjii-msft]

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

[heaths]

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

[kasper93]

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.

[heaths]

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.