Make VSWhere useful for developers

[IanKemp]

What developers need is a utility, located in a well-known and unchanging location, that can be invoked with no arguments, to return an absolute path to the tool they need.

VSWhere is not that utility. VSWhere is a Swiss army knife that has about 50 million arguments and outputs, yet still fails to return anything that's actually useful to developers. It is a tool that was written for Microsoft's wants, not the needs of developers who use Microsoft's tools.

It is a tool that is setting up every developer who uses it for disaster, because when - not if - Microsoft decides to change the location of MSBuild.exe, every script that tries to find MSBuild by concatenating the output of VSWhere with MSBuild\15.0\Bin\MSBuild.exe is going to break. Best case, the script is written well and the worst that happens is a "file not found" message; worst case... well, how many scripts have you seen that do path concatenation the absolutely wrong way, such that the file not being found will cause issues up to and including execution of the completely wrong EXE?

A utility that simply returns the absolute path to MSBuild, however, is almost foolproof: it either returns a valid path, and MSBuild runs; or it returns a bad path, and you try to run a nonexistent executable, and get a "file not found" message, and things break.

That is the utility VSWhere needs to be. Start off by adding support for getting the absolute path to MSBuild (you can obscure it behind half-a-dozen arguments if you must); someone who needs to locate a different VS tool can submit a pull request that follows the pattern set for MSBuild.

[3F]

It is already so. This tool just covers new installation API as an user-end command-line tool which distributed constantly in known place (only with new VS versions #41).

So you can wrap anything even via simple batch scripts like hMSBuild just for searching msbuild.exe and so on.

[heaths]

Thank you for your feedback, but MSBuild is not the only EXE for which people search using vswhere to find the root location of, by default, Visual Studio. You can tailor its use for your specific scenarios - which aren't not always the same as for others - using the switches that opt into additional behavior as you seem fit. By default, all complete, released instances are enumerated.

Sure, it may be a Swiss army knife, but that is to be useful for many cases and not just a single case when all you need is a flat head screwdriver.