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

Improve VS2017 detection by leveraging VSWhere.exe #6

New Issue
Closed
opened 2026-01-30 21:39:29 +00:00 by claunia · 9 comments
claunia commented 2026-01-30 21:39:29 +00:00
Owner
Copy Link

Originally created by @khouzam on GitHub (Aug 14, 2017).

With support for multiple versions of VS2017, using vswhere.exe to detect the location of an appropriate install would be easier.

Originally created by @khouzam on GitHub (Aug 14, 2017). With support for multiple versions of VS2017, using vswhere.exe to detect the location of an appropriate install would be easier.
claunia added the Issue-FeatureHelp Wanted labels 2026-01-30 21:39:29 +00:00
claunia commented 2026-01-30 21:39:30 +00:00
Author
Owner
Copy Link

@amweiss commented on GitHub (May 8, 2019):

Happy to get a PR in for this @zadjii-msft , would the preferred approach be to require choco install vswhere, just require a version of vswhere be on the PATH before running razzle or something else?

@amweiss commented on GitHub (May 8, 2019): Happy to get a PR in for this @zadjii-msft , would the preferred approach be to require `choco install vswhere`, just require a version of `vswhere` be on the PATH before running razzle or something else?
claunia commented 2026-01-30 21:39:30 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 8, 2019):

Is it possible to use the VSWhere that ships with the installer? @heaths may know if that’s okay.

From: Adam Weiss notifications@github.com
Sent: Wednesday, May 8, 2019 10:48:24 AM
To: microsoft/Terminal
Cc: Subscribed
Subject: Re: [microsoft/Terminal] Improve VS2017 detection by leveraging VSWhere.exe (#13)

Happy to get a PR in for this @zadjii-msfthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzadjii-msft&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=z2mvfucA%2BZS2QMP1NAYWY7Gh2YQjRNwrT2QTNQ12i6E%3D&reserved=0 , would the preferred approach be to require choco install vswhere, just require a version of vswhere be on the PATH before running razzle or something else?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F13%23issuecomment-490584055&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=SBNCCVD6SSVYhM%2FrJmQtWdWnVK5NX5H8kRazFwCxYnk%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADNHLGXQLGVUTOO6QCQOKELPUMG6RANCNFSM4DW2U4MA&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=0SCjXNqsyWPLCbh0WCGXCMVrSvmlHbU5oUyop8%2B%2BOBs%3D&reserved=0.

@DHowett-MSFT commented on GitHub (May 8, 2019): Is it possible to use the VSWhere that ships with the installer? @heaths may know if that’s okay. ________________________________ From: Adam Weiss <notifications@github.com> Sent: Wednesday, May 8, 2019 10:48:24 AM To: microsoft/Terminal Cc: Subscribed Subject: Re: [microsoft/Terminal] Improve VS2017 detection by leveraging VSWhere.exe (#13) Happy to get a PR in for this @zadjii-msft<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzadjii-msft&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=z2mvfucA%2BZS2QMP1NAYWY7Gh2YQjRNwrT2QTNQ12i6E%3D&reserved=0> , would the preferred approach be to require choco install vswhere, just require a version of vswhere be on the PATH before running razzle or something else? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FTerminal%2Fissues%2F13%23issuecomment-490584055&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=SBNCCVD6SSVYhM%2FrJmQtWdWnVK5NX5H8kRazFwCxYnk%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADNHLGXQLGVUTOO6QCQOKELPUMG6RANCNFSM4DW2U4MA&data=01%7C01%7Cduhowett%40microsoft.com%7C1bd93eb3ba0a420be52408d6d3dd5ef8%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=0SCjXNqsyWPLCbh0WCGXCMVrSvmlHbU5oUyop8%2B%2BOBs%3D&reserved=0>.
claunia commented 2026-01-30 21:39:30 +00:00
Author
Owner
Copy Link

@amweiss commented on GitHub (May 8, 2019):

I have VS2019 and VS2019 Preview installed through the installer and the included VSWhere was not added to my path by default. I can try to locate vswhere to then locate msbuild, or just require it be on the path somehow for it to run.

@amweiss commented on GitHub (May 8, 2019): I have VS2019 and VS2019 Preview installed through the installer and the included VSWhere was not added to my path by default. I can try to locate `vswhere` to then locate `msbuild`, or just require it be on the path _somehow_ for it to run.
claunia commented 2026-01-30 21:39:31 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (May 8, 2019):

We don't add it to the PATH because it's not an oft-enough used tool. Every directoryt added to PATH merely increases lookup time.

I recommend you acquire vswhere.exe via nuget or chocolatey, as described here. You can use the version we always install to "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" but you're rolling the dice on what features you get. For example, I just resolved a bug against vswhere because someone was using that path and trying to use the -find parameter that was added later. The only way to be sure you get the features you want is either use the ones we added initially (but that started in 15.2) or acquire it yourself. You can also redist it, which is what build systems like Azure Pipelines do (it's used by various built-in tasks).

@heaths commented on GitHub (May 8, 2019): We don't add it to the PATH because it's not an oft-enough used tool. Every directoryt added to PATH merely increases lookup time. I recommend you acquire vswhere.exe via nuget or chocolatey, as described [here](https://github.com/microsoft/vswhere/wiki/Installing). You can use the version we always install to "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" but you're rolling the dice on what features you get. For example, I just resolved a bug against vswhere because someone was using that path and trying to use the `-find` parameter that was added later. The only way to be sure you get the features you want is either use the ones we added initially (but that started in 15.2) or acquire it yourself. You can also redist it, which is what build systems like Azure Pipelines do (it's used by various built-in tasks).
claunia commented 2026-01-30 21:39:31 +00:00
Author
Owner
Copy Link

@amweiss commented on GitHub (May 8, 2019):

Thanks, I just got a version of razzle.cmd working with the chocolatey version and the -find parameter actually. It seems a bit heavy handed to put a choco install vswhere in razzle.cmd, but that would ensure it's a one step setup process. I'll post a PR in a few hours we can worth though, but on my environment it worked well.

@amweiss commented on GitHub (May 8, 2019): Thanks, I just got a version of `razzle.cmd` working with the chocolatey version and the `-find` parameter actually. It seems a bit heavy handed to put a `choco install vswhere` in `razzle.cmd`, but that would ensure it's a one step setup process. I'll post a PR in a few hours we can worth though, but on my environment it worked well.
claunia commented 2026-01-30 21:39:31 +00:00
Author
Owner
Copy Link

@heaths commented on GitHub (May 8, 2019):

Then why not use nuget? You already are using nuget generally, so put "vswhere" in your .nuget\packages.config file and it will get pulled if needed* whenever nuget restore is run in the repo. That's what a lot of our repos do - even vswhere itself. You could assume a hardcoded path in your script even, but you'll have to remember to update it if you ever update to a newer version in packages.config. Or do what we do and scan for it.

@heaths commented on GitHub (May 8, 2019): Then why not use nuget? You already are using nuget generally, so put "vswhere" in your .nuget\packages.config file and it will get pulled if needed* whenever `nuget restore` is run in the repo. That's what a lot of our repos do - even vswhere [itself](https://github.com/microsoft/vswhere/blob/develop/.nuget/packages.config). You could assume a hardcoded path in your script even, but you'll have to remember to update it if you ever update to a newer version in packages.config. Or [do what we do](https://github.com/microsoft/vswhere/blob/develop/tools/test.ps1) and scan for it.
claunia commented 2026-01-30 21:39:31 +00:00
Author
Owner
Copy Link

@amweiss commented on GitHub (May 9, 2019):

I have a version started here: #606 but I can't get the build tools v141 working in VS2019. I don't want to mix that into this change so I want to get that sorted out before I make it a real PR.

@amweiss commented on GitHub (May 9, 2019): I have a version started here: #606 but I can't get the build tools v141 working in VS2019. I don't want to mix that into this change so I want to get that sorted out before I make it a real PR.
claunia commented 2026-01-30 21:39:31 +00:00
Author
Owner
Copy Link

@amweiss commented on GitHub (May 10, 2019):

@khouzam you should be able to close this now that #606 was merged.

@amweiss commented on GitHub (May 10, 2019): @khouzam you should be able to close this now that #606 was merged.
claunia commented 2026-01-30 21:39:32 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 10, 2019):

Fixed in #606,
Thanks!

@DHowett-MSFT commented on GitHub (May 10, 2019): Fixed in #606, Thanks!
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 Help Wanted Issue-Feature
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#6
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?