win: find and setup for VS2017 #1130

joaocgreis · 2017-02-25T03:51:53Z

Reviewed #1103 :

Filter VS2017 installations using the installed components, to make sure the installation found is usable.
Added logging.

cc @refack @bzoz can you review?

refack · 2017-02-25T23:13:53Z

Personally I would move logic from the C# to JS. I like that you use more of the information available to us from the COM, but I would filter and choose in JS. I also like the idea of a log, but maybe if the C# prints everything, there will be no need.
I'll take some ideas to #1103 and to windows-autoconf 😉

Reviewed-By: João Reis <reis@janeasystems.com>

joaocgreis · 2017-02-27T19:30:29Z

Updated, fixed failure when there's no usable installation and store the MSBuild executable path in config so that it can respect --msvs_version. I considered filtering on the JS side, but it can be a huge list of components and is easy enough to do on the C# side. We can always improve if necessary.

Tested (with node v7 on Windows 7):

Several installations of VS2017, where only one is usable
VS2017 installed but not usable
After uninstalling VS2017
VSBT2015 and VS2017 side by side (--msvs_version works)
Run npm as a normal user
On Windows 10, node v4, running as a normal user

bnoordhuis · 2017-02-28T11:06:39Z

Is this PR taking a dependency on powershell and the C# compiler? That... seems unfortunate.

PR-URL: #1130 Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>

joaocgreis · 2017-02-28T12:39:04Z

~~Landed in b456dd0~~

@bnoordhuis it does, but those two are installed by default everywhere I've looked. To make node-gyp work out of the box in the platforms we support, it's either this, comtypes as in #1101, or have an executable committed. This worked great everywhere I've tested, but it's not impossible that there is some uncommon Windows configuration that breaks. Based on actual issues, we can fix or decide for any of the other options.

bnoordhuis · 2017-02-28T12:41:46Z

Merging is a little premature. There has been no sign-off from a committer and you didn't run the CI either.

refack · 2017-02-28T12:44:48Z

LGTM(ish) I'll make a future PR with some more changes 😉

joaocgreis · 2017-02-28T12:45:41Z

Took it back, I took @bzoz sign-off as enough, this has been under discussion in #1101 and #1103 for a long time. I'll run CI.

refack · 2017-02-28T12:49:43Z

lib/build.js

@@ -14,7 +14,9 @@ var fs = require('graceful-fs')
  , mkdirp = require('mkdirp')
  , exec = require('child_process').exec
  , processRelease = require('./process-release')
-  , win = process.platform == 'win32'
+  , win = process.platform === 'win32'
+if (win)


You don't need this if you already injected config.variables.msbuild_path (which is smart)

joaocgreis · 2017-02-28T12:54:35Z

CI:

joaocgreis · 2017-02-28T13:41:19Z

@bnoordhuis CI is green, do you want to review? I think this is important to have, what should I do to move this forward?

joaocgreis · 2017-03-05T17:19:51Z

cc @nodejs/node-gyp @nodejs/build

joaocgreis · 2017-03-08T18:13:44Z

Updated: changed the MSBuild dependency component. Installing only MSBuild does not make it usable for C++ if the workload is not installed. But installing "Visual Studio C++ core features" is enough, includes MSBuild.exe and the necessary files to make it usable.

Fishrock123 · 2017-03-13T15:24:20Z

@bnoordhuis, @rvagg PTAL

rvagg · 2017-03-14T00:57:28Z

working on this now FYI, had to get a few other pressing things out of the way but I'm reviewing and testing this out for myself now

rvagg

Requested some minor changes and a bit of feedback. If the 2015->2017 thing is a GYP hack then the rest are just minor fixes.

Tested in a few different configurations myself, works as it should. The .cs thing is unfortunate but I understand the rationale and don't think it's ultimately a big deal. 👍 and thanks for the hard work folks.

rvagg · 2017-03-14T07:01:34Z

lib/configure.js

@@ -137,6 +139,18 @@ function configure (gyp, argv, callback) {
    // disable -T "thin" static archives by default
    variables.standalone_static_library = gyp.opts.thin ? 0 : 1

+    if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) {


would you mind inverting this? reads really badly. (win && (!gyp.opts.msvs_version || gyp.opts.msvs_version === '2017'))

rvagg · 2017-03-14T07:02:59Z

lib/configure.js

+    if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) {
+      const vsSetup = findVS2017()
+      if (vsSetup) {
+        gyp.opts.msvs_version = '2015'


are we forcing this to make GYP happy, or is this (and the next line) a mistake?

We are forcing this to make GYP happy, and to avoid pulling https://chromium-review.googlesource.com/#/c/433540/ (which did not land yet) as a floating patch, since floating patches seem to be avoided here.

rvagg · 2017-03-14T07:04:33Z

lib/find-vs2017.js

+
+  var vsSetup
+  try {
+    const vsSetupRaw = execSync(psQuery, { encoding: 'utf8' })


var for consistency, also given that node-gyp still works for very old versions of Node

sorry, I mean, s/var/const in this entire file

rvagg · 2017-03-14T07:05:43Z

lib/configure.js

@@ -137,6 +139,18 @@ function configure (gyp, argv, callback) {
    // disable -T "thin" static archives by default
    variables.standalone_static_library = gyp.opts.thin ? 0 : 1

+    if (win && !(gyp.opts.msvs_version && gyp.opts.msvs_version !== '2017')) {
+      const vsSetup = findVS2017()


s/const/var

rvagg · 2017-03-14T07:07:01Z

lib/Find-VS2017.cs

@@ -0,0 +1,262 @@
+// powershell -ExecutionPolicy Unrestricted -Version "2.0" -Command "&{Add-Type -Path Find-VS2017.cs; [VisualStudioConfiguration.Main]::Query()}"


does this file need source attribution and/or copyright? or is it ours?

This was submitted by @refack in #1103 , I believe it was adapted from the python COM API by @bzoz in #1101 , which in turn got the GUIDs and API from the nuget package upstream. @refack can you confim?

I wrote it myself. GUIDs extracted from interop

Please add

// Copyright 2017 - Refael Ackermann // Distributed under MIT style license // See accompanying file LICENSE at https://github.com/node4good/windows-autoconf

I recommend using updated file https://github.com/node4good/windows-autoconf/blob/master/tools/GetVS2017Configuration.cs

joaocgreis · 2017-03-14T11:12:59Z

@rvagg updated, PTAL. About the 2015->2017 GYP hack, my comment above is hidden by GitHub:

We are forcing this to make GYP happy, and to avoid pulling https://chromium-review.googlesource.com/#/c/433540/ (which did not land yet) as a floating patch, since floating patches seem to be avoided here.

joaocgreis · 2017-03-14T20:26:11Z

v6.10.0: https://ci.nodejs.org/view/All/job/nodegyp-test-commit/45/ (green)
v4.8.0: https://ci.nodejs.org/view/All/job/nodegyp-test-commit/46/ (green)
v0.12.18: https://ci.nodejs.org/view/All/job/nodegyp-test-commit/47/ (green)

rvagg · 2017-03-15T04:42:14Z

@joaocgreis let's get this published today. Clean it up and get it merged and we'll publish and then PR npm to get it there too. Ping me on IRC when you're around and want to move forward.

PR-URL: #1130 Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Rod Vagg <rod@vagg.org>

joaocgreis · 2017-03-15T11:58:18Z

Landed in ae141e1

rvagg · 2017-03-15T20:28:58Z

v3.6.0 released, thanks for the hard work on this @refack, @joaocgreis, @bzoz and anyone else who contributed, not a small effort

rvagg · 2017-03-15T20:51:30Z

Attempted PRs to npm (I always get seem to get this process wrong):

lts: node-gyp@3.6.0 npm/npm#16049
latest: node-gyp@3.6.0 npm/npm#16050

rvagg · 2017-03-17T00:52:33Z

OK, looks like we might not be getting v4 compatibility for VS 2017 from npm unless we patch it ourselves I guess @nodejs/lts npm/npm#16049

refack · 2017-03-17T01:01:57Z

What's needed for v4 compat? Can I help?

gibfahn · 2017-03-17T13:34:33Z

@refack issue is that Node 4 is going into maintenance mode soon, so there might not be another update to npm before that time. The ping to @nodejs/lts is for the LTS team to decide whether it's worth doing another v4 release to pick up the npm update.

FWIW, I think it's worth updating to support VS2017 in Node 4 (but then I won't have to do the release).

refack · 2017-03-17T13:37:36Z

@gibfahn, thanks
Best I can do is make sure VS2017 changes to node-gyp are fully compatible with v4 (I'll add it to my CI matrix)

Fishrock123 · 2017-03-20T17:57:18Z

OK, looks like we might not be getting v4 compatibility for VS 2017 from npm unless we patch it ourselves I guess

I'm not sure that was read from the comment correctly but it could be the case.

gibfahn · 2017-03-20T21:57:19Z

Unless Node.js is planning on doing a new v4 release for this(?), I don't see us doing a new npm@2 release.

Based on that comment, if we can get it into Node v4, we can get it into npm.

Node v4 goes into maintenance mode on 2017-04-01, i.e. in ten days. Whichever way we go, we need to make a decision ASAP.

refack · 2017-03-21T02:18:25Z

👎
#1151 v3.6.0 might break a lot of actions out there 😟

refack · 2017-03-21T16:21:34Z

@joaocgreis, @rvagg Let's fast track #1153

refack · 2017-03-24T17:52:06Z

"Bring back VS150COMNTOOLS"
I urge everyone else to up vote at https://developercommunity.visualstudio.com/content/problem/35325/missing-vs150comntools.html

refack · 2017-04-18T15:58:44Z

lib/Find-VS2017.cs

+                else if (id == "Microsoft.VisualStudio.Component.VC.Tools.x86.x64")
+                    hasVCTools = true;
+                else if (id.StartsWith(Win10SDKPrefix))
+                    Win10SDKVer = Math.Max(Win10SDKVer, UInt32.Parse(id.Substring(Win10SDKPrefix.Length)));


Bug found with new SDK #1144

AndrewPardoe · 2017-04-20T22:38:04Z

The officially supported vswhere tool is now available as part of the install starting today with Visual Studio 15.2 preview 2: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed-with-visual-studio-2017/. This doesn't fix all the existing installs of VS 2017 but going forward you can now detect the VS install locations and whether C++ tools are available from a scripted environment. I hope this helps your scenario.

am11 · 2018-02-19T14:31:23Z

One approach is to download VSWhere as a fallback if not available and completely rely on it to find VS2017:

# powershell
$vswherePath = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe";
if (!(Test-Path $vswherePath)) {
    $latestReleaseTag = $(curl https://api.github.com/repos/Microsoft/vswhere/releases/latest | `
                          ConvertFrom-Json) | % { $_.tag_name };

    $vswherePath = "$pwd\vswhere.exe";
    curl -O $vswherePath `
        https://github.com/Microsoft/vswhere/releases/download/$latestReleaseTag/vswhere.exe;
}

$vsBase = &$vswherePath -latest -products * `
              -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 `
              -property installationPath;

if (!$vsBase) {
    throw "VS or MSVC component is not installed";
}

&"$vsBase\vc\Auxiliary\Build\vcvars64.bat";
# now link.exe, cl.exe etc. are in PATH

# or write vsvars path to stdout for the caller (MSBuild Exec task)
echo $vsBase\vc\Auxiliary\Build\vcvars64.bat;

However, in practice, vswhere is available in a deterministic location when we have VS or buildtools installed, then downloading is sort of moot if we don't want to support non-ProgramFiles installs (e.g. https://github.com/dotnet/corert/blob/378ad6a/src/BuildIntegration/findvcvarsall.bat).

Patch Set 4: Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. Patch-set: 4

Patch Set 4: > Patch Set 4: > > Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) > > In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. We could also assume the default install location and allow users to set an environment variable if they have a non-default install. That is what Chrome is doing - the complexity of the COM solution didn't seem justified, at least initially. Patch-set: 4 Reviewer: Gerrit User 1128439 <1128439@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>

Patch Set 4: > Patch Set 4: > > Sorry, but this is not the way to do that. Registry key approach was discussed downstream in nodejs, Heath Stewart who is responsible for the VS installer said explicitly that the registry entry is not supported (nodejs/node-gyp#1103 (comment)) > > In node-gyp we used Rafael's powershell script that can query VS COM server (nodejs/node-gyp#1130). We used that to find VS and set environment variables. IMHO we should do the same thing here. Obviously, but I like this solution for this project, it's good enough... ... ... ... ... ... ... You know what, I'll make another PR with the full script Patch-set: 4 Reviewer: Gerrit User 1188132 <1188132@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>

Patch Set 9: > Patch Set 9: > > > Patch Set 9: > > > > > AFAIK that all correct. > > > also: > > > - MS are not likely to change this logic till SP1 (if even) > > > - Meanwhile `GYP` based projects (i.e. `node-gyp`, `node`, `libuv` that I know of) have been floating patches of their own... > > > > > > Detection logic aside, we should land either this or 453201, since all the VS2017 issues are becoming a major PITA > > > > Okay, I agree that we should land something as this has dragged on too long and we should have VS2017 support. > > > > For now, since > > 1) we have no reason to think that the registry-based approach doesn't work, and that that's what GN is using, > > 2) and that I don't know who can actually review the PS/C# code for correctness or support it besides you, > > > > I think the registry approach is the better way to go, and hopefully MS will change their course. If it turns out that the registry approach breaks or becomes otherwise problematic, I'm fine w/ taking this code for both GYP and GN until we get a better solution. > > > > Does that work for you? > > If you mean 453201, sure! Ohh, P.S. the C#/PS code has landed in `node-gyp` nodejs/node-gyp#1130 and `Boost/build` boostorg/build#170 But NM Patch-set: 9 Reviewer: Gerrit User 1188132 <1188132@3ce6091f-6c88-37e8-8c75-72f92ae8dfba>

joaocgreis mentioned this pull request Feb 25, 2017

Detect VS2017 #1103

Closed

win: find and setup for VS2017

1f79c98

Reviewed-By: João Reis <reis@janeasystems.com>

joaocgreis force-pushed the joaocgreis-H2O-vs2017 branch from aa8626e to 1f79c98 Compare February 27, 2017 19:02

bzoz approved these changes Feb 28, 2017

View reviewed changes

joaocgreis pushed a commit that referenced this pull request Feb 28, 2017

win: find and setup for VS2017

b456dd0

PR-URL: #1130 Reviewed-By: João Reis <reis@janeasystems.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>

joaocgreis closed this Feb 28, 2017

joaocgreis reopened this Feb 28, 2017

refack suggested changes Feb 28, 2017

View reviewed changes

fixup: unnecessary require

2dd811b

refack approved these changes Feb 28, 2017

View reviewed changes

fixup: change MSBuild dependency

034a330

joaocgreis mentioned this pull request Mar 8, 2017

Visual Studio 2017 #1056

Closed

rvagg requested changes Mar 14, 2017

View reviewed changes

rvagg mentioned this pull request Mar 14, 2017

win,build: add Visual Studio 2017 support nodejs/node#11084

Closed

3 tasks

joaocgreis added 2 commits March 14, 2017 11:00

fixup: s/const/var

5a06bef

fixup: De Morgan

5faa488

refack mentioned this pull request Mar 14, 2017

win: enable build with vs2017 nodejs/node#11852

Closed

3 tasks

rvagg approved these changes Mar 15, 2017

View reviewed changes

joaocgreis closed this Mar 15, 2017

bzoz mentioned this pull request Mar 15, 2017

Add support for Visual Studio 2017 #1101

Closed

joaocgreis mentioned this pull request Mar 15, 2017

win,build: add Visual Studio 2017 support nodejs/node#11867

Closed

3 tasks

gibfahn mentioned this pull request Mar 22, 2017

Potential Semver Minor Backports nodejs/Release#188

Closed

31 tasks

refack reviewed Apr 18, 2017

View reviewed changes

refack mentioned this pull request Apr 23, 2017

Bump gyp 19495aa #1183

Closed

2 tasks

DeeDeeG mentioned this pull request Aug 19, 2020

Hacking on Atom Core: Update build requirements to be accurate atom/flight-manual.atom.io#630

Merged

		@@ -0,0 +1,262 @@
		// powershell -ExecutionPolicy Unrestricted -Version "2.0" -Command "&{Add-Type -Path Find-VS2017.cs; [VisualStudioConfiguration.Main]::Query()}"

win: find and setup for VS2017 #1130

win: find and setup for VS2017 #1130

Conversation

joaocgreis commented Feb 25, 2017

refack commented Feb 25, 2017

joaocgreis commented Feb 27, 2017

bnoordhuis commented Feb 28, 2017

joaocgreis commented Feb 28, 2017 • edited Loading

bnoordhuis commented Feb 28, 2017

refack commented Feb 28, 2017 • edited Loading

joaocgreis commented Feb 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joaocgreis commented Feb 28, 2017

joaocgreis commented Feb 28, 2017

joaocgreis commented Mar 5, 2017

joaocgreis commented Mar 8, 2017 • edited Loading

Fishrock123 commented Mar 13, 2017

rvagg commented Mar 14, 2017

rvagg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joaocgreis commented Mar 14, 2017

joaocgreis commented Mar 14, 2017

rvagg commented Mar 15, 2017

joaocgreis commented Mar 15, 2017

rvagg commented Mar 15, 2017

rvagg commented Mar 15, 2017

rvagg commented Mar 17, 2017

refack commented Mar 17, 2017

gibfahn commented Mar 17, 2017

refack commented Mar 17, 2017

Fishrock123 commented Mar 20, 2017

gibfahn commented Mar 20, 2017

refack commented Mar 21, 2017

refack commented Mar 21, 2017

refack commented Mar 24, 2017

Choose a reason for hiding this comment

AndrewPardoe commented Apr 20, 2017

am11 commented Feb 19, 2018

joaocgreis commented Feb 28, 2017 •

edited

Loading

refack commented Feb 28, 2017 •

edited

Loading

joaocgreis commented Mar 8, 2017 •

edited

Loading