Using VS 2017 generator and corresponding tools

[andyleejordan]

Hello,

This project is great, I am making much use of it for our CMake driven build system for Mesos (on Windows). Today I tried (and finally succeeded) to get the extension to use the Visual Studio 2017 CMake generator. Unfortunately, the current procedure is a bit round-about.

To succeed, I added:

    "cmake.preferredGenerators": [
        "Visual Studio 15 2017 Win64"
    ],

to my settings.json. This much works (but should be available by default).

But I could not get cmake.configureEnvironment to by happy with a modified PATH. When I added what I believed to be the correct path, configuring failed with ENOENT, as if I'd messed up the PATH to CMake. I tried variations of the following:

    "cmake.configureEnvironment": {
        "PATH": "${env.PATH};C:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/"
    }

So I currently resort to opening the x64 Native Tools Command Prompt for VS 2017, and launching code from their such that it inherits the path correctly.

This works, and I started investigating what it'd take to support 2017 in the extension. Here's where things get a bit hairy.

VS150COMNTOOLS isn't set in my normal environment; I have to open the developer command prompt to read it.

The folder layout has changed. The extension currently uses VS140COMNTOOLS/../../VC/vcvarsall.bat, but it won't be as simple as adding VS150COMNTOOLS, because the setup script is instead at VS150COMNTOOLS/../../VC/Auxiliary/Build/vcvarsall.bat. I tracked down this article which supposedly "explains how to programmatically locate all VS instances on a machine".

Given the correct information, I think adding easy-to-use VS 2017 support is doable, but I'm not familiar with the Visual Studio Code extension development process, nor with exactly how you'd prefer to set up the defaults.

I look forward to expanded support!

Thanks,

Andy

[vector-of-bool]

Thanks for the useful information!

I haven't worked on Windows for a few months (since VS 2017 was released), so I haven't had quite the personal urgency to get it working. I want to make sure that 2017 is usable, especially now that it is officially RTM. I'll have a look and see what this will take to get working.

Also, the problem with your PATH setting: The extension does not do the smarts to actually expand any environment variables within those settings. It's probably possible, I just haven't gotten around to it. That means, in your case, the only valid path entry will be the 2017 VC path (hence the failure).

[lygstate]

We should detecting vscode from registry but not environment variable.

[vector-of-bool]

After a lengthy hiatus, I'm going to jump on this issue as soon as possible.

[maddouri]

Not sure how this could be done, but if it helps, MS released vswhere which is supposed to be able to find VS 2017+ ... perhaps someone could have a look at their code for some inspiration? (or just ship it with CMake Tools on windows?)

Also, according to this article:

Starting in the latest preview release of Visual Studio version 15.2 (26418.1-Preview), you can now find vswhere installed in “%ProgramFiles(x86)%\Microsoft Visual Studio\Installer” (on 32-bit operating systems before Windows 10, you should use “%ProgramFiles%\Microsoft Visual Studio\Installer”).

[vector-of-bool]

@maddouri, it may be best to just download vswhere on first startup and use it when discovering installs, since it can be fairly complicated. I'd rather not implement a very buggy VS 2017 finding tool myself. :smile:

[vector-of-bool]

Tada! This should work in the next release. I've decided to go with the pre-installed vswhere binary, as it's the most reliable way to find it. This will limit the auto-detection to Update 2, but I'm alright with that.