microsoft/vswhere

Locate Visual Studio 2017 and newer installations

Visual Studio Locator

Over the years Visual Studio could be discovered using registry keys, but with recent changes to the deployment and extensibility models a new method is needed to discover possibly more than one installed instance. These changes facilitate a smaller, faster default install complimented by on-demand install of other workloads and components.

vswhere is designed to be a redistributable, single-file executable that can be used in build or deployment scripts to find where Visual Studio - or other products in the Visual Studio family - is located. For example, if you know the relative path to MSBuild, you can find the root of the Visual Studio install and combine the paths to find what you need.

You can emit different formats for information based on what your scripts can consume, including plain text, JSON, and XML. Pull requests may be accepted for other common formats as well.

vswhere is included with the installer as of Visual Studio 2017 version 15.2 and later, and can be found at the following location: %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe. The binary may be executed from that location as needed, installed using popular package managers including WinGet, or the latest version may be downloaded from the releases page.

Example

If you wanted to find MSBuild - now installed under the Visual Studio 2017 and newer installation root - you could script a command like the following to run the latest version of MSBuild installed. This example uses the new -find parameter in our latest release that searches selected instances for matching file name patterns. You can tailor what instances you select with parameters like -version or -prerelease to find specific versions you support, optionally including prereleases.

@echo off
setlocal enabledelayedexpansion

for /f "usebackq tokens=*" %%i in (`vswhere -latest -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe`) do (
  "%%i" %*
  exit /b !errorlevel!
)

You can find more examples in our wiki.

Feedback

To file issues or suggestions, please use the Issues page for this project on GitHub.

License

This project is licensed under the MIT license.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

vswhere's Issues

Cannot distinguish releases from prereleases

Some internal and external users have asked for a way to filter out prereleases. Visual Studio ships a number of prereleases to our preview channel before releasing the final updated versions. Currently, this information is not exposed through the query API but we are working to make it so.

This is a tracking item and a request for comments on how to expose this ability.

Currently, I have a prototype which,

1. Filters out prereleases by default.
2. Adds a IsPrerelease : boolean property.
3. Adds a -prerelease switch parameter to vswhere.exe to allow prereleases in results.

This means prereleases will no longer show up in results by default, but you can opt into considering prereleases with the -prerelease switch.

[Feature request] An option for -requires to detect 15063/1703 Windows SDK

Just as the title says, I'm not sure if this is the right place to ask this (since -requires options may be defined by Visual Studio's SxS installer. But I'll give it a try (since Windows SDK can be installed with its standalone installer, too).

Add -listproducts option

This option would list all the available product name options that could be used with the -products arg option. This could also be hardcoded in the help if it isn't dynamic.

Thanks,
SLDR
(Stephen L. De Rudder)

XP Build?

Any chance this could be built to run on Windows XP? We're stuck in legacy land with XP build machines at present which have Visual Studio 2010 installed on them, however running vswhere.exe gives the following error:

Getting the full path to MSBuild.exe

Hi

I feel like I'm missing some obvious way to determine the full path to MSBuild.exe.
To illustrate, here's where we're at currently:

1. Run vswhere.exe -latest -requires Microsoft.Component.MSBuild -property installationFolder.

2. The return value "C:\Path\To\VisualStudio\Root" seems useless, because we have to make an additional assumption reg. the location of MSBuild.exe inside that folder.
   We could append "\MSBuild\15.0\MSBuild\bin\MSBuild.exe", but that seems to defeat the purpose of not making assumptions/including hard coded paths in our build scripts.

3. Run vswhere.exe -latest -requires Microsoft.Component.MSBuild -property installationVersion.

4. The return value "15.0.26430.6" seems useless, because the actual path is "C:\Path\To\My\VisualStudio\Root\15.0\" which means we'd again need to do additional handling, e.g. using either a 2 or 3 digit substring based on whether the major revision is less than/greater than 10.

Return location of Visual Studio settings file

With Visual Studio starting from version 15.3 using a installation specific location for its settings file, it would be nice if vswhere could also return the location of the settings file used by a Visual Studio installation.

Unable to locate the MSBuild component when only "Build tools for Visual Studio 2017" is installed

I only have the "Build Tools for Visual Studio 2017" installed on our build server. I need to locate the MSBuild.exe file. Running "vswhere" does not return anything back. I also tried running "vswhere -latest -requires Microsoft.Component.MSBuild"

I am missing something here? Is it not supposed to work with the build tools?

Non deterministic error: 0x57 "version" parameter is not supported

I have two machines, both Windows 7 with VS 2015 installed.
One machine has also VS 2017 installed. I'm using vswhere version 2.1.3

I try to run the following command to get the path for VS2015:
vswhere.exe -legacy -version "[14,15)" -property installationPath -nologo

On the machine with VS2017 installed the path is successfully determined.
On the other machine the following error is reported:
Error 0x57: The "version" parameter is not supported

I already made sure that the same version of vswhere is used...

Create a tools nuget package

It would be very useful if this were shipped to nuget.org as a tools nuget package so build scripts (cake, psake etc) can download and leverage.

Help is wrong about format

I think the places of json and text are swapped.

This seems to be due to /src/vswhere.lib/Formatter.cpp?

vswhere -all does not find the installation of BuildTools

I have installed:

1. VS Enterprise in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
2. BuildTools in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin

Running vswhere is discovering 1, but not 2.

Actual results

PS C:\temp> .\vswhere.exe -all
Visual Studio Locator, version 1.0.14-beta
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: db7eafa1
installDate: 29/01/2017
installationName: VisualStudio/15.0.0-RC.4+26206.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
installationVersion: 15.0.26206.0
displayName: Visual Studio Enterprise 2017 RC
description: Microsoft DevOps solution for productivity and coordination across teams of any size
PS C:\temp>

Expected results

Listing both installation of MSBuild.

vswhere.pdb is shipped in NuGet package

The vswhere.pdb file was accidentally shipped in the NuGet package. This should be removed since it is archived online.

Incorrect PowerShell examples at Find-MSBuild wiki

Examples "Starting with version 1.0.32" and "Starting with version 1.0.40" are
incorrect, they assume that $path is the path to MSBuild.exe and invoke it
with $args. But the actual $path is something like

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise

So either the returned $path is different from expected or this line is missing

    $path = Join-Path $path 'MSBuild\15.0\Bin\MSBuild.exe'

If it is the latter case, the question is: can we avoid using the hardcoded
sub-path MSBuild\15.0\Bin\MSBuild.exe on resolving the MSBuild.exe path?

-legacy -latest returns wrong instance

I've been testing out 1.0.50 and using the -legacy -latest, and not getting the results I expected. I have 2 instances found v10.0 and v14.0 however the -latest switch returns v10.0, it this expected?

C:>VSWHERE.EXE -nologo -legacy -all
instanceId: VisualStudio.14.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 14.0
installationVersion: 14.0

instanceId: VisualStudio.10.0
installationPath: c:\Program Files (x86)\Microsoft Visual Studio 10.0
installationVersion: 10.0

C:>VSWHERE.EXE -nologo -legacy -latest
instanceId: VisualStudio.10.0
installationPath: c:\Program Files (x86)\Microsoft Visual Studio 10.0
installationVersion: 10.0

C:>VSWHERE.EXE
Visual Studio Locator, version 1.0.50
Copyright (C) Microsoft Corporation. All rights reserved.

Synthetic property with path to vcvarsall.bat

I think it would be useful if you add a synthetic property with a path to vcvarsall.bat.
VS2015 and before: %installationPath%\VC\vcvarsall.bat
VS2017 and later: %installationPath%\VC\Auxiliary\Build\vcvarsall.bat

Error when calling in batch file

I've created a batch file named vs.cmd with the following content:

@echo off

for /f "usebackq tokens=*" %%i in (`"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -prerelease -latest -products * -requires Microsoft.Component.MSBuild -property installationPath`) do (
  set InstallDir=%%i
)

if exist "%InstallDir%\MSBuild\15.0\Bin\MSBuild.exe" (
  echo MSBuild installed in: %InstallDir%\MSBuild\15.0\Bin\MSBuild.exe
)

(Needed to fix the vswhere.exe path because it's not in the %PATH%.)

Here's the output:

"\Microsoft" kann syntaktisch an dieser Stelle nicht verarbeitet werden.

So that didn't work. Not sure how this is supposed to work at all because the backtick operator doesn't seem to be supported in Windows CMD. Is this a Bash script actually?

vswhere only shows query API version sometimes

The query API version - as of release 1.0.62 - is displayed in the logo (if installed) only if we load the query API. If running vswhere -?, for example (or a syntax error occurs), it is not displayed. Consider loading the query API earlier (even for usage help) to always show the query API version (if installed).

Was vswhere.exe supposed to find a "Build tools" install?

On a build agent I installed the "Build tools for Visual Studio 2017" ( taken from https://www.visualstudio.com/downloads/ , under "Other Tools and Frameworks", "Build Tools for Visual Studio 2017" ).

Running vswhere doesn't find that install. Shouldn't it?

PS S:\temp> .\vswhere -latest -requires Microsoft.Component.MSBuild
Visual Studio Locator version 1.0.62 [query version 1.9.77.53636]
Copyright (C) Microsoft Corporation. All rights reserved.

PS S:\temp>

It does find the install for a "legacy" version, if that's relevant:

PS S:\temp> .\vswhere -legacy
Visual Studio Locator version 1.0.62 [query version 1.9.77.53636]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: VisualStudio.10.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 10.0\
installationVersion: 10.0
PS S:\temp>

-legacy does not list all installed versions

I am trying to find the installation path of Visual Studio 2008.
I get following output by invoking vswhere.exe -legacy:

instanceId: VisualStudio.14.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 14.0\
installationVersion: 14.0

instanceId: VisualStudio.12.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 12.0\
installationVersion: 12.0

instanceId: VisualStudio.11.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 11.0\
installationVersion: 11.0

Unfortunately VisualStudio.9.0 is missing altough it is installed on my machine.

Version range filter includes wrong instance (-version [12.0,14.0] returns 10.0)

I want to identify a supported legacy VS instance, however by running:

vswhere -legacy -version [12.0,14.0]

it returns:
Visual Studio Locator, version 1.0.58
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: VisualStudio.12.0
installationPath: D:\Program Files (x86)\Microsoft Visual Studio 12.0
installationVersion: 12.0

instanceId: VisualStudio.10.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 10.0
installationVersion: 10.0

Being outside the version range filter, the 10.0 is part of the output.

What possible format of the directory name for installed MSBuild tools

3F/hMSBuild#3

So for clarify,
What possible format of versions for this directory - \{major}.0\ or it may be like \{major}.{minor}\ ? some other ?

Version property doesn't work correctly

Using -version [15.0,16.0) returns an error - Error 0x57: The version "[15.0,16.0)" is not a valid version range.

This error happens on Windows 10 with vswhere 1.0.58, but works correctly on Windows 8.

Proposal: exit code != 0 when requested asset(s) aren't installed

We're trying out vswhere as a means to get installation info of 2017 and also need a way to check if 2017 is at all installed. Based on the later, we know if we should continue or not (installing an extension).

Now, invoking vswhere on a machine where a requested product and/or prerequisite is not found, what about returning an exit code other than 0 for that? Preferable one even with some semantics (where that applies).

Hence, doing vswhere -products * on a machine where 2017 never was installed would give me 123 instead of 0.

vshwere hangs

Running with any parameters but /? results in a failure:

Windows 10 (not creator update)
Visual Studio 2015 only

Failure to load query API shows header even for no-logo formats

If the query API cannot be loaded when passing -format json, the program header is still shown and no empty array is printed, i.e. []. The idea is to treat absence of the query API as no instances installed so this should work as if no instances match the specified parameters.

Using vswhere to find BuildTools

Someone suggests to use vswhere to locate msbuild. However, it seems that current release of vswhere does not list "BuildTools edition of VS". I understand that BuildTools is not a real edition of VS, but rather an extracted component from VS. (It is located inside VS install directory.)

Could vswhere also list plain BuildTools installation? Or could anyone suggest a proper way to locate msbuild? Or, is checking the directories the only proper way to locate msbuild as, for instance, gulp-msbuild does.)

The "-legacy" option does not appear to work with the "-version" option.

Using the "-legacy" and "-version" options together does not work. It always outputs all legacy versions. Either these options should actually work together -OR- using them together should produce an error.

Not compatible with older versions?

I was hoping that I could rely on this tool to find any version of Visual Studio. But apparently it only works with the Visual Studio 2017 (probably and later) but not with e.g. Visual Studio 2015.

It would be cool if there was some legacy detection so that this tool could be used as a single utility to find installed Visual Studio versions—regardless of whether they are new or old.

Setting mode to _O_U16TEXT breaks PowerShell output capture

To support localized text in the console, _setmode(_fileno(stdout), _O_U16TEXT) was added but this breaks PowerShell's ability - and possibly other tools - to parse the output it was expecting using the OEM or ANSI code page.

After a lot of troubles with iostreams and Unicode and discussions with the VC++ team, it may be better to switch back to stdio streams.

vswhere 1.0.60 crashes on Windows 7

v1.0.60 crashes on my Windows 7(x64, SP1, Japanese, VS2010, VS2015 are installed.).
It's OK with my Windows 10.

The error information of the event log is below.

Faulting application name: vswhere.exe, Version: 1.0.60.6534, Timestamp: 0x58ec036f
Faulting module name: vswhere.exe, Version: 1.0.60.6534, Timestamp: 0x58ec036f
Exception code: 0xc0000005
Fault offset: 0x00001cfe
Faulting process id: 0x1ac8
Faulting application start time: 0x01d2b28045bd8f81
Faulting application path: C:\Users\userid\iq\nuget\packages\vswhere.1.0.60\tools\vswhere.exe
Faulting module path: C:\Users\userid\iq\nuget\packages\vswhere.1.0.60\tools\vswhere.exe
Report  ID: 83713e5d-1e73-11e7-8c5e-f8b156a57939

Note: The user belongs to the Administrators Group.

New vswhere parameter that will find any available product

Something like -products *

Invalid JSON output with CP932 encoding

Got a bug report on my own project regarding invalid JSON. Is vswhere generating invalid json? Or do I need to set the environment properly to get valid output?

RFE: Improved semantics when multiple products are installed

If there are multiple products installed, it would be nice to have one or both of the following features:

1. An option to output the products in order from the "best" one down, e.g. Enterprise first, etc.

2. Alternatively, there could be an option, perhaps called "-best", that returns only the best installed product for a particular version. It should, of course, work with the "-version" option.

System error messages may not be localized

On a system where the UI language and locale are set to "ja-JP", ERROR_INVALID_PARAMETER text is printed wrong.

C:\> vswhere.exe -foo
Error 0x57: Unknown parameter: foo: ???????????????

Notice also that there is no program header information.

vswhere hangs on Windows 2008 R2

I first reported my issues over on vsts-agent, but I'm fairly sure it belongs here.
microsoft/azure-pipelines-agent#1090

Windows 2008 R2 server with the latest windows updates.

for /L %n in (1,1,100) do "vswhere.exe" -version [15.0,15.1) -latest -format json

If I run this, it will eventually hang. I might have to run that a couple times, but on my machine I can always get it to hang.

I ran it a few times on a Windows 2016 server and I never got a hang.

I tried v1.0.62 and v2.0.2

Bettre qualify the Nuget id

Hi

The of the wshere nuget package is set to vswhere. This is IMO not enough qualified as suggedted by the NuGet documentation. Thus I would suggest to change this id to something like <id>Microsoft.VisualStudio.Locator</id> so that the NuGet.org namespace be not overpolluted by single id.

vswhere -version '[15.1,16.0)' doesn't find 15.1.0 (26403.7)

I have the latest VS 2017 installed:

If I run vswhere -version '[15.1,16.0)' all I get is:

Visual Studio Locator version 1.0.62 [query version 1.9.77.53636]
Copyright (C) Microsoft Corporation. All rights reserved.

But if I run vswhere -version '[15.0,16.0)' I get:

Visual Studio Locator version 1.0.62 [query version 1.9.77.53636]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: 9df01e36
installDate: 12/04/2017
installationName: VisualStudio/15.1.0+26403.7
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise
installationVersion: 15.0.26403.7
displayName: Visual Studio Enterprise 2017
description: Microsoft DevOps solution for productivity and coordination across teams of any size
enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
channelId: VisualStudio.15.Release
channelPath: C:\Users\david\AppData\Local\Microsoft\VisualStudio\Packages_Channels\4CB340F5\catalog.json
channelUri: https://aka.ms/vs/15/release/channel
releaseNotes: https://go.microsoft.com/fwlink/?LinkId=660090#15.1.26403.07
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660105

Shouldn't I get a match for the first range?

Clarification on parameter -version

The range of the parameter -version can be given as follows -version A,B. Here the filter seems to include all installations with a version >= A and < B.

The query for Version 15 only must then be formulated as -version 15,16 and not -version 15,15. Is that correct?

In my opinion <= B would have been more logical from the perspective of querying a range. But others might already rely on this specific filtering behaviour.

vswhere hangs

Sometimes when I call vswhere with '-latest -legacy' multiple times it will hang indefinitely.

This happens both with the release and debug version, but a colleague couldn't reproduce the issue with a fairly similar setup.

My machine has VS2015 Pro, and VS2017 Pro. It also has remnants of uninstalled versions going back to VS2008 but these are correctly not being detected when vswhere works correctly.

Attaching and pausing the process running a debug build shows two threads with the following stack traces:

 	ntdll.dll!_NtWaitForSingleObject@12�()	Unknown
 	ntdll.dll!_RtlpWaitOnCriticalSection@8�()	Unknown
 	ntdll.dll!_RtlEnterCriticalSection@4�()	Unknown
 	ntdll.dll!_LdrGetProcedureAddressEx@20�()	Unknown
 	ntdll.dll!_LdrGetProcedureAddress@16�()	Unknown
 	KernelBase.dll!_GetProcAddress@8�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_a463b7b0560cfcaf9b17f27c6ef46564> >(enum __acrt_lock_id,class <lambda_a463b7b0560cfcaf9b17f27c6ef46564> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!___acrt_IsValidLocaleName@4�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__expandlocale�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__wsetlocale�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> >(enum __acrt_lock_id,class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__crt_seh_guarded_call<void>::operator()<class <lambda_c76fdea48760d5f9368b465f31df4405>,class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> &,class <lambda_e927a58b2a85c081d733e8c6192ae2d2> >(class <lambda_c76fdea48760d5f9368b465f31df4405> &&,class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> &,class <lambda_e927a58b2a85c081d733e8c6192ae2d2> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> >(enum __acrt_lock_id,class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> >(enum __acrt_lock_id,class <lambda_e378711a6f6581bf7f0efd7cdf97f5d9> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__crt_seh_guarded_call<void>::operator()<class <lambda_70818de7b02deff9841e8b0962a60ed9>,class <lambda_2af78c5f5901b1372d98f9ab3177dfa6> &,class <lambda_f51fe5fd7c79a33db34fc9310f277369> &>(class <lambda_70818de7b02deff9841e8b0962a60ed9> &&,class <lambda_2af78c5f5901b1372d98f9ab3177dfa6> &,class <lambda_f51fe5fd7c79a33db34fc9310f277369> &)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__wsetlocale�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!_wcscpy_s�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!_setlocale�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!std::_Locinfo::_Locinfo_ctor(class std::_Locinfo *,char const *)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!std::_Locinfo::_Locinfo(char const *)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!std::ctype<wchar_t>::_Getcat(class std::locale::facet const * *,class std::locale const *)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!std::use_facet<class std::ctype<wchar_t> >(class std::locale const &)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!SetupHelper::Trim(wchar_t const * const,wchar_t * *)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!SetupHelper::ParseVersion(wchar_t const *,unsigned __int64 *)	Unknown
>	vswhere.exe!InstanceSelector::Less(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a={...}, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b={...}) Line 49	C++
 	vswhere.exe!InstanceSelector::Select::__l26::<lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a={...}, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b={...}) Line 150	C++
 	vswhere.exe!std::_Debug_lt_pred<bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) &,_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &,_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &>(InstanceSelector::Select::__l26::bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) & _Pred=bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b){...}, _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & _Left={...}, _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & _Right={...}, const wchar_t * _File=0x00bac6a8, unsigned int _Line=2766) Line 948	C++
 	vswhere.exe!std::_Insertion_sort_unchecked<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > *,bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) >(_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _First=0x00606448, _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _Last=0x00606450, InstanceSelector::Select::__l26::bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) & _Pred=bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b){...}) Line 2766	C++
 	vswhere.exe!std::_Sort_unchecked1<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > *,int,bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) >(_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _First=0x00606448, _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _Last=0x00606450, int _Ideal=2, InstanceSelector::Select::__l26::bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) & _Pred=bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b){...}) Line 2901	C++
 	vswhere.exe!std::_Sort_unchecked<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > *,bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) >(_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _First=0x00606448, _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > * _Last=0x00606450, InstanceSelector::Select::__l26::bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) & _Pred=bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b){...}) Line 2908	C++
 	vswhere.exe!std::sort<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > > > >,bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) >(std::_Vector_iterator<std::_Vector_val<std::_Simple_types<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > > > > _First={...}, std::_Vector_iterator<std::_Vector_val<std::_Simple_types<_com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > > > > _Last={...}, InstanceSelector::Select::__l26::bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > &) _Pred=bool <lambda>(const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & a, const _com_ptr_t<_com_IIID<ISetupInstance,&_GUID_b41463c3_8866_43b5_bc33_2b0676f7f42e> > & b){...}) Line 2916	C++
 	vswhere.exe!InstanceSelector::Select(IEnumSetupInstances * pEnum=0x00606310) Line 147	C++
 	vswhere.exe!wmain(int argc=3, const wchar_t * * argv=0x00603738) Line 49	C++
 	vswhere.exe!invoke_main() Line 79	C++
 	vswhere.exe!__scrt_common_main_seh() Line 259	C++
 	vswhere.exe!__scrt_common_main() Line 302	C++
 	vswhere.exe!wmainCRTStartup() Line 17	C++
 	kernel32.dll!@BaseThreadInitThunk@12�()	Unknown
 	ntdll.dll!___RtlUserThreadStart@8�()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8�()	Unknown

>	ntdll.dll!_NtWaitForSingleObject@12�()	Unknown
 	ntdll.dll!_RtlpWaitOnCriticalSection@8�()	Unknown
 	ntdll.dll!_RtlEnterCriticalSection@4�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!___acrt_lock�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__crt_seh_guarded_call<void>::operator()<class <lambda_3518db117f0e7cdb002338c5d3c47b6c>,class <lambda_b2ea41f6bbb362cd97d94c6828d90b61> &,class <lambda_abdedf541bb04549bc734292b4a045d4> >(class <lambda_3518db117f0e7cdb002338c5d3c47b6c> &&,class <lambda_b2ea41f6bbb362cd97d94c6828d90b61> &,class <lambda_abdedf541bb04549bc734292b4a045d4> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_b2ea41f6bbb362cd97d94c6828d90b61> >(enum __acrt_lock_id,class <lambda_b2ea41f6bbb362cd97d94c6828d90b61> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__acrt_lock_and_call<class <lambda_e69574bed617af4e071282c136b37893> >(enum __acrt_lock_id,class <lambda_e69574bed617af4e071282c136b37893> &&)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!___acrt_getptd_noexit�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!___acrt_thread_attach�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!___scrt_dllmain_crt_thread_attach�()	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!operator new(unsigned int,struct std::nothrow_t const &)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!operator new(unsigned int,struct std::nothrow_t const &)	Unknown
 	Microsoft.VisualStudio.Setup.Configuration.Native.dll!__DllMainCRTStartup@12�()	Unknown
 	ntdll.dll!_LdrpCallInitRoutine@16�()	Unknown
 	ntdll.dll!_LdrpInitializeThread@4�()	Unknown
 	ntdll.dll!__LdrpInitialize@8�()	Unknown
 	ntdll.dll!_LdrInitializeThunk@8�()	Unknown

Locate MSBuild sample is not up-to-date

I am using https://github.com/Microsoft/vswhere/wiki/Find-MSBuild to detect MSBuild 15 in batch file, but except the first snippet for batch file, the other two do not work, even if 1.0.47 version is used. Why?

Doesn't locate Visual Studio 2015 installation

Hi,

I have side by side VS 2017 and VS 2015.
When I execute the tool, it prints only VS 2017 location.

Wouldn't be great idea that this should spit out all VS installations as it sounds?

vswhere returns Preview version even without the -prerelease switch

I updated vswhere to 2.0.2 because I needed the new behavior described in the help message:

-prerelease    Also searches prereleases. By default, only releases are searched.

But it doesn't work as described. It always returns the 15.3 Preview version, which I want to filter out. How can I get the path for the latest stable version?

Update wiki/install

https://github.com/Microsoft/vswhere/wiki/Find-MSBuild
I've sketched a paragraph here as diif, inst.upd.txt
and here as is:

 

[update April 20, 2017 - vswhere is now installed with visual studio 2017]
As of release 15.2 (26418.1-Preview - Installer version 15.0.26418.1) the VS installer will include vswhere.exe and place it in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer (on 32-bit operating systems before Windows 10, it will be %ProgramFiles%\Microsoft Visual Studio\Installer).
_{On exsisting installation you can run the installer with --update --quiet to quitly get in to upgrade}
[/end update]

---

Feature request: return a non-zero exit code when no VS is found

Currently the program exits with ERROR_SUCCESS even if no version of Visual Studio was found. So for example if you are just trying to get the installation path, the calling script has to look for an empty string.

Would there be any objection to changing the return code to an error if no version is found? I can send a pull request.

Add support to find all versions of visual studio

Can this be modified to find previous versions of visual studio
while the functionality is useful for finding 2017 we have a lot of legacy projects with dependencies as early as 2010

.\vswhere.exe -version "[11.0,16.0)"

only returns 2017 skus

Searching of MSBuild tools: vswhere + VS as an initial tool by default

How about to provide this (or similar) tool by default with VS as front-controller (into one known unified place) for simple requests about simple informations like searching of available msbuild tools and other informations about all installed VS instances ?

It's important for any small tools like this, that contains all logic via single batch file etc.
I mean just look the gnt.bat (full logic for work with nuget packages: creating new, installing, etc. via msbuild) and tell me, how we should now ? +vswhere.exe ?

For any searching of msbuild tools it looked like this msbuild-helper before (to build in any places like CI build-servers, any custom user's env etc. - easy and works well)

this:

for /f "usebackq tokens=1* delims=: " %%i in (`vswhere -latest -requires Microsoft.Component.MSBuild`) do (
  if /i "%%i"=="installationPath" set InstallDir=%%j
)
...

is much more useful when your vswhere (or something else) will be provided initially as a simple console tool and located in already known place (to aggregate any requests as front-controller as I said above).

This is possible by MS ? or how it should be now for something like above ?

Update 1

Final solutions to find msbuild.exe from VS2017:

Via batch scripts ( no powershell, no dotnet cli )

For online machines, now appeared this - https://github.com/3F/hMSBuild

A single compiled batch file ~19 Kb that can be embedded inside any scripts or other batch files:

• https://github.com/3F/hMSBuild/releases/latest

Usage is same as it would be same for msbuild.

Usage: hMSBuild [args to hMSBuild] [args to msbuild.exe or GetNuTool core]
------

Arguments:
----------
 -no-vs        - Disable searching from Visual Studio.
 -no-netfx     - Disable searching from .NET Framework.
 -no-vswhere   - Do not search via vswhere.

 -vsw-version {arg}  - Specific version of vswhere. Where {arg}:
     * 2.6.7 ...
     * Keywords:
       `latest` - To get latest remote version;
       `local`  - To use only local versions;
                  (.bat;.exe /or from +15.2.26418.1 VS-build)
...

Solution by Microsoft

here:

After further discussion internally, we're going to add vswhere.exe to a known location (such as %CommonProgramFiles%) in an upcoming servicing release, which will address the original issue as proposed by @3F at the top of the thread. This will give you the flexibility to use ...

Update 2

here by @heaths:

vswhere is now available as part of the install starting today with Visual Studio 15.2 preview 2:

Update 3

Just removed direct links to hMSBuild 1.x ( 2017, which are still actively referenced ). Please use latest versions:

🧱 Compiled text-based embeddable pure batch-scripts for searching of available MSBuild tools.

• https://github.com/3F/hMSBuild ( .bat ~19 KB, no powershell, no dotnet cli )

Support for older versions

A lot of software would benefit from for it, if the utility provides backward compatibility for older version of VS. For example, the following PowerShell script covers some basic use-cases:

Click to expand PS script

function Get-VisualStudioVersionAndPath
{
  [CmdletBinding()]
  [Alias("gvsvp")]
  PARAM()
  process
  {
    foreach($v in @("15.0", "14.0", "12.0", "11.0", "10.0"))
    {
      try
      {
        $path = (gp "HKLM:\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7" -Name $v -EA Stop).$v
        return @($v, $path)
      }
      catch { <# ignore #> }
    }

    throw [System.InvalidOperationException] "Couldn't find suitable version of Visual Studio!"
  }
}

# usage (throws)
$VSVersion,$VSPath = Get-VisualStudioVersionAndPath
# or compactly
$vsver,$vsp = gsvp

# usage (no-throw)
$VSVersion,$VSPath = Get-VisualStudioVersionAndPath -ErrorAction SilentlyContinue
# or compactly
$vsver,$vsp = gsvp -ea 0

There are many scripts laying around on the internet to perform similar operations; finding VS version/path, finding MSBuild version/path, Windows SDK version/path etc. Would be super cool, if this utility masters some more use cases completely, so we at the downstream solely rely on one and only nuget package (nuget install vswhere -o . -ex && vswhere\tools\vswhere -help).

Use new argument `-property` in examples

User installer

For Boost C++ Libraries we have essentially decided to require users to provide vswhere in the path if they want VS2017 support. There are three possibilities for users to get that:

1. vswhere is installed as part of VS2017 in the PATH (in some future update).
2. vswhere is installed as part of a Windows update.
3. Users install it on their own.

For option 3 we would need to point users to an installer they can use that handles installing the executable in the PATH. Hence, we are asking for such an installer to be made in a trust worthy way. I.e. signed by Microsoft and available from a Microsoft source.

Is `VC\Tools\MSVC\14.10.25017\bin\HostX64\x64` for MSVC tool consistent?

If I do where cl on VS2017 Command Prompt then I see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe. I don't think this is a consistent path for future VS2017.x or VS201x, is there a way to get a path that can work for future versions of Visual Studio?

The current sample on the main page uses MSBuild which has simpler path, but still it uses version number 15.0 which makes it incompatible with future VS versions.