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

[3F]

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 )

[heaths]

We are considering this, but even if we did in a subsequent update, VS2017 RTW already shipped. vswhere was meant to be redistributed as needed, so I the meantime and for VS2017 RTW support you could consider adding the file to the repo.

[3F]

VS2017 RTW already shipped

Yes, I noticed -_- ... and I don't know how to easily solve this problem instead of adding vswhere for a lot of public repos.

Moreover, as you can see this can be a simple small script-tool for end-users. So I don't know what to do at all for this cases (well, I know but...), because now it requires ... omg.

As I see, gnt.bat tool above should correctly work via tool from .NET Framework, thus nuget-packages are still not problem and we can distribute vswhere automatically (like for other my X tool for additional complex build-scripting that wrapped by single bat file and distributed via nuget server), however: the nuget package will not useful for offline machines :(, so the easy way, yes, to distribute 'as is' together with repo. That's of course amazing for simply finding path to the msbuild tools <_<

Need to think -_-

We are considering this

Good ! I hope to see something from next patch-releases at least.

Thanks,

[KindDragon]

or how it should be now for something like above ?

You can try to install it from Chocolatey, It will be automatically added to PATH

[3F]

It will be automatically added to PATH

the problem not for path to vswhere because we can still use gnt like:

:: to get the vswhere & vsSBE packages
gnt /p:ngpackages="vswhere;vsSBE.CI.MSBuild"

:: we're ready for vswhere
%vswhere% -latest -requires Microsoft.Component.MSBuild
...

:: build Conari project via powerful vsSBE scripts & msbuild tools from found path by vswhere
%msbuild% -notamd64 "Conari.sln" /l:"CI.MSBuild.dll" ... || goto err
...
etc.

but thanks, it's first time when I hear about chocolatey :)

[grafikrobot]

The Boost C++ Libraries project lobbied for this to be included before the release went out. But those requests failed. Most likely the VS release manager didn't consider this a high-priority issue. But now we have a situation where many different projects like Boost, Cmake, etc will end up including a patchwork of incompatible detection methods in their repos.

For Boost including the executable of this utility might be an option.. If it where not for the license. As, if you can believe, the Boost license is less restrictive than the MIT license in use for vswhere. My suggestion would be to relicense vswhere to the "Public Domain" or the "Boost License", or some other license that doesn't require license terms for binary inclusion.

[heaths]

@grafikrobot looking at the boostorg/boost repo I see a number of bootstrap scripts that pull down files (granted, Python scripts). Perhaps the MIT license is more restrictive but you merely need to pull it. You don't even have to include it in your repo. That's why the vswhere.exe executable itself (not ZIP'd or anything) is available here on GitHub. How is pulling that different from pulling other build-required scripts?

[grafikrobot]

@heaths I'm not sure where you see the bootstrap pulling anything. As it's designed to operate entirely offline. For example it's possible to download a Boost release unplug your network cable (or equivalent) and then do a complete build. Which is actually required for some platforms like some mainframes and other specialized hardware that are not internet connected.

[heaths]

@grafikrobot what is this? https://github.com/boostorg/boost/blob/master/bootstrap.bat

Even if we did install it with our installer now, what about those customers with RTW?

[grafikrobot]

@heaths This https://github.com/boostorg/boost/blob/master/bootstrap.bat is the script that checks if you've already built the build system. If not, it tries to build it. If that fails it tells the user some alternatives.

As for RTW people.. Good question. Boost could choose to not support it. Or only support it with a big disclaimer and some user manual configuration (i.e. we'd fail to bootstrap and the message would suggest that if they have RTW they do the manual config).

[grafikrobot]

@heaths PS.. Also for RTW customers Microsoft could choose to install vswhere as part of the next OS patch set so that everyone has it installed. Wouldn't help the customers that use OS version that are past end-of-life. But VS2017 probably doesn't run on those.

[OlafvdSpek]

@grafikrobot Why an OS update and not just a VS update?
And why not have users use "Developer Command Prompt for VS 2017" until MS fixes this?

@heaths That's what updates are for.

[heaths]

@OlafvdSpek users are not forced to take updates for VS. They might have to in some scenarios, but they have never been required. Many organizations want to do rigorous testing before ever taking updates. Even if we did, some users may not be connected or take an update, which means they're on RTW.

[OlafvdSpek]

@heaths True, so one might decide not to support RTW..

[grafikrobot]

Copying my "solution" from another issue here for the benefit of those in this topic..

Never mind.. After trying to use the vswhere tool to determine the cl.exe location with some modicum of sanity I've given up. My current suggestion will be to avoid this tool and wait for real solution from Microsoft. In the mean time we will tell users that if they want VS2017, aka cl.exe 14.10 (or 14.1 depending on whom you ask) they will need to run from the VS command prompt or set the VS150COMNTOOLS environment variable manually.

Thank you for my wasted time.. Goodbye.