Skip to content

Added check for VS generator using vswhere.exe #180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 8, 2019

Conversation

nicole-mcg
Copy link
Contributor

@BurningEnlightenment @unbornchikken

I tried to take a larger approach to this in #178 but discovered mid way that my solution didn't work with all workflows. Here is a solution that will add the generator check using vswhere.exe, but will continue if it fails.

@unbornchikken
Copy link
Member

Ok, finally I got a Win laptop with VC++ 2019 Build Tools. I'm gonna verify this later today.

@nicole-mcg
Copy link
Contributor Author

@unbornchikken Any update on this?

@jmcker
Copy link
Contributor

jmcker commented Jul 6, 2019

Would you still be open to expanding the 'partial install' idea that you presented in #178?

I've opened #183 with verification of detection for a couple common use cases.

Really looking forward to seeing this and #177 released to support a minimal VS2019 setup!

@nicole-mcg
Copy link
Contributor Author

@jmcker #178 was originally based on the assumption that my method would work for all workflows. This has PR has the same effect as that one, but with this PR it will continue with the current methods of finding msbuild.exe

Some workflows will still have to resort to more hacky or unreliable methods of finding msbuild.exe

@jmcker
Copy link
Contributor

jmcker commented Jul 7, 2019

This PR, in its current state, does not detect the VS2017 or VS2019 Build Tools installs that I have (via vswhere or current methods of finding msbuild). I think this is ultimately because the registry key that _isBuildToolsInstalled searches for is no longer created on fresh installs.

Modifying _getGeneratorFromVSWhere and including -products * and -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 seems to extend detection to any type of VS installation that has a Visual C++ compiler.

EDIT: Just found the -latest flag here which would remove the need to iterate over the version strings.

I'm happy to make my own PR to discuss the changes after this merges, especially since this might be part of a larger shift to vswhere. But I figured I'd at least bring it up here since you already did most of the work!

Toolset.prototype._getGeneratorFromVSWhere = async(function*() {
    let programFilesPath = _.get(process.env, "ProgramFiles(x86)", _.get(process.env, "ProgramFiles"));
    let vswhereCommand = path.resolve(programFilesPath, "Microsoft Visual Studio", "Installer", "vswhere.exe");
    const vswhereOutput = yield processHelpers.exec(`"${vswhereCommand}" -products * -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationVersion`);

    if (!vswhereOutput) {
        return null;
    }

    let versions = vswhereOutput.trim().split('\r\n');

    // Find the max since the first result isn't necessarily the top supported
    let maxVer = 0;
    for (let ver of versions) {
        ver = ver.trim();
        ver = ver.substring(0, ver.indexOf("."));
        ver = parseInt(ver);

        if (ver > maxVer) {
            maxVer = ver;
        }
    }

    if (maxVer == 0) {
        return null;
    }

    return {
        14: "Visual Studio 14 2015",
        15: "Visual Studio 15 2017",
        16: "Visual Studio 16 2019",
    }[maxVer] || null;
});

@unbornchikken
Copy link
Member

unbornchikken commented Jul 8, 2019

Yeah, I still have issues with this. I've accidentally installed a previous version of VS Tools. Then uninstalled, then installed the latest. And it seems the older version got selected for CMake.js.

Anyway I'm merging this, and looking forward to see a PR from @jmcker. Thanks for your efforts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants