Detect VS2017

[refack]

Based on @bzoz's #1101 but without python `comtypes'

Also bumped gyp to latest version and updated out patch files

[refack]

(changed COM tool from an exe to a powershell script)

[joaocgreis]

Node-gyp must support Windows 7/2008R2 while Node does, and those versions of Windows ship with PowerShell 2.0. The module you use here seems to require at least version 3. We could ask users to update PowerShell, but there have been issues in the past from users locked in corporate environments with no permissions to install anything, so this might be troublesome to most and impossible to some.

Using an executable opens an issue of trust in the committed file. We could get around this by setting up a job in node's release infrastructure to compile and sign an executable to use here, but only if must be.

@refack what issue do you see with comtypes? I'd rather not add the dependency, but so far it seems to be the easiest for all users. Either way we decide to go, thanks for submitting this, it's great to be able to broaden discussion by having more alternatives!

[refack]

I'll check if I can back port the script...
Keep in mind, it's a fall back to try to detect VS2017 specificaly, doesn't it's installation upgrades powershell anyway?

• as for the exe, I get it.
  ** as for comtypes I think it's major overkill, and the "prevailing winds" is to reduce dependency on python, not increase it for this "tiny" COM query 🤔😕

[bzoz]

@refack I just checked this on Windows 7 - after installing VS2017 and selecting Desktop Development with C++, powershell is still at version 2

[refack]

Yep just did that too 😣 (also encountered the ExecutionPolicy issue)
But i'm not giving up... I'll find a way!

[refack]

P.S. same config (VS2017 build tools on Windows 7SP1):

gyp ERR! stack Error: Command failed: c:\bin\dev\python27\python.EXE \\REFAELUX\code\3party\node-gyp\find_vs2017.py
gyp ERR! stack Traceback (most recent call last):
gyp ERR! stack   File "\\REFAELUX\code\3party\node-gyp\find_vs2017.py", line 173, in <module>
gyp ERR! stack     main()
gyp ERR! stack   File "\\REFAELUX\code\3party\node-gyp\find_vs2017.py", line 158, in main
gyp ERR! stack     installs = GetVS2017CPPBasePath()
gyp ERR! stack   File "\\REFAELUX\code\3party\node-gyp\find_vs2017.py", line 106, in GetVS2017CPPBasePath
gyp ERR! stack     iface = CreateObject(GUID('{177F0C4A-1CD3-4DE7-A32C-71DBBB9FA36D}'))
gyp ERR! stack   File "\\REFAELUX\code\3party\node-gyp\comtypes\comtypes\client\__init__.py", line 238, in CreateObject
gyp ERR! stack     obj = comtypes.CoCreateInstance(clsid, clsctx=clsctx, interface=interface)
gyp ERR! stack   File "\\REFAELUX\code\3party\node-gyp\comtypes\comtypes\__init__.py", line 1225, in CoCreateInstance
gyp ERR! stack     _ole32.CoCreateInstance(byref(clsid), punkouter, clsctx, byref(iid), byref(p))
gyp ERR! stack   File "_ctypes/callproc.c", line 945, in GetResult
gyp ERR! stack WindowsError: [Error -2147221164] Class not registered

Apparently the COM interface doesn't get registered

[refack]

Unless you install the .NET 4.6 SDK

[joaocgreis]

@refack any luck with PowerShell v2?

[refack]

@joaocgreis just cracked it (and added an undocumented Registry approach as backup)

[joaocgreis]

I've tested, and I could not get this to work because of spaces in the path. Also, the registry key approach does not provide the SDK.

@heaths this looks for the path in the registry at HKLM\Software\Microsoft\VisualStudio\SxS\VS7. Can we trust the value in this registry key? Is it likely to be removed in the future?

[heaths]

Paths could always have spaces. Make sure the path is quoted and you shouldn't have a problem. No registry values are supported for VS2017. Whatever you found is probably just a left-over that should've been removed. MSIs are singletons and may have nothing to do with where VS instances are installed.

[refack]

Fixed path escaping issue, and now the code works with Powershell "core".
Registry "hack" is a backup measure anyway ...

P.S. I refactored my code into a package (it's has no dependecies of it's own) what might be the push back of adding it as a dependency?

[refack]

As my detection package is getting traction, and bug fixes, I believe it's worth the add.

@bnoordhuis @kunalspathak I think now it's mature enough to cc you :)

[heaths]

While I appreciate the community working together to fill gaps - being a long-time open source contributor myself - I'm curious how using the batch scripts are easier than acquiring the PowerShell module:

install-module vssetup -scope currentuser # only needed once
$installationPath = get-vssetupinstance | select-vssetupinstance -latest | select-object -expand InstallationPath

I will be keeping these up to date with new functionality as we bring it online.

[AndrewPardoe]

First, I agree with Heath: The PowerShell solution is probably best for most users.

I had a discussion with the Boost folks that lays out the options. This thread may be interesting to you: boostorg/build#157

[refack]

@heaths It's a change to the underlying system. While reasonable for developers, node-gyp is an automation module that runs as part of setup of different systems.
Also one tenet of the node.js way is "Keep everything local / Leave no trace" emblemized with the ubiquitous node_molues directory (with all it's pros and cons).
Second: it require access to the internet, and permission to install such things. Again, not an assumption node-gyp can take.
If you can escalate these concerns, that would be great. I believe the "C++ Build Tools" configuration is an example of helping these use cases.

[heaths]

@refack FWIW, I'm working to finish up a single native binary that can return information in a number of formats. A prototype actually ships in the tools subdirectory of the Microsoft.VisualStudio.Setup.Configuration.Native NuGet package, which is what several VC projects are using. You might take a look at that, as the eventual new project will also grow over time. These are also fully supported.

[refack]

@heaths That's sounds promising. Maybe also also consider implementing IDispatch so we could use it directly with Powershell's New-Object -ComObject and cscript / JScript?

[refack]

@heaths Where's the best place to leave feedback on "Microsoft.VisualStudio.Setup.Configuration.Native"? I have one request; we need the version number for installed SDKs so we could populate the <WindowsTargetPlatformVersion>10.0.14393.0</WindowsTargetPlatformVersion> field in vcxproj files

[refack]

P.S. IMHO nuget is very node.jsy 😜

[AndrewPardoe]

@refack, given that NuGet and node.js were designed around the same time, that's not a surprise. They both reflect how the world was thinking about packages at the time.

Given node.js is a year earlier, there might be inspiration, but I'm not the one to comment on that.

[heaths]

@refack re: PowerShell, people should just use the VSSetup module. Even with IDispatch support, enumerating instances through the IEnumXXX-style interface is a PITA and doesn't jive with PowerShell. The point of the module was to make something easily acquirable and easy to use. If you don't want to take a dependency on a network connection, it's license to redistribute.

We can consider adding IDispatch for scripting support, but PowerShell was meant to replace all that. It would be a lower priority item.

re: feedback, consider it heard. We can consider how to do that, but the data on which the query API works doesn't store that. The more data we store, we slow the query API down. That's only one type of question to ask, but I'm sure other people have others. We can't really store every conceivable answer. Instead, it would be better that the Windows SDK - which is actually a system singleton (i.e. it's still MSI-based and will be for the foreseeable future since it's so big and used by things outside VS) - write something like that. I will pass along feedback.

For now, you could do something like the following as long as their package ID pattern holds:

get-vssetupinstance | select -expand Packages | where Id -match 'Win10SDK_\d' | select Version

[refack]

@heaths Thanks again for listening. (as for figuring out the SDK that's almost exaclty what I'm doing in my CS script)

[joaocgreis]

@heaths we must support Windows 7 and 2008R2 as shipped, with Powershell v2. I did not manage to get the VSSetup module to work with it, is there a way? I'm not thrilled about landing a binary either - even if we can trust the binary's content we might run into issues with antivirus software because node-gyp must be usable as downloaded from the internet (e.g. after updating npm). Currently, the solution here, using the COM API, seems to be the best one.

@refack can you move the gyp bump to a different PR, or is it required for this? Also, the commit with the Gyp floating patch that you had before looked good, can you bring it back (or is there a reason not to)?

About using a package: @refack can you commit to always supporting the same versions of Windows that node does? @nodejs/node-gyp are there other reasons why we might not want this as a package?

[refack]

I can do the minimal patch, give me a few minutes

[refack]

Did a minimal patch, no package.
But I shall return

Muhhhhaaaaaaa

[heaths]

I have published a release of vswhere - a single-file, native executable you can redistribute - at https://github.com/Microsoft/vswhere. It currently emits data in plan text and JSON and would be fairly easy to use. For example, to find the root path to the latest version installed for native tools:

for /r "usebackq tokens=1* delims=: " %%i in (`vswhere.exe -latest -requires Microsoft.VisualStudio.Workload.NativeDesktop`) do (
  if /i "%%i"=="installationPath" set dir=%%j
)

rem %dir% now contains the root installation path, if available

[refack]

I tweaked the .bat file to be more "polite" if it can't find the COM.
cc @joaocgreis

[joaocgreis]

Reviewed and opened #1130 with a slightly modified version.

[refack]

I brough back windows-autoconf, since it now has general MSVS detection logic, which enabled me to remove almost half of build.js.
I have it CI on a windows machine at AppVeyor
I'm working on eliminating more of node-gyp's VS decection code, and adding it's test suite as a dependency for passing the CI...

[refack]

@bnoordhuis @joaocgreis
Can we have vote this vs node-gyp#1130 ? See all the red lines, code you don't need to worry about ;)
cc @nodejs/node-gyp @nodejs/build

[refack]

CI now passes node-gyp test suite

[refack]

Getting better coverage from AppVeyor VS2015 and vs2017 pass node-gyp's test suite

[refack]

Great news we landed VS2017 support to GYP https://chromium-review.googlesource.com/c/453201/

[AndrewPardoe]

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.

[refack]

@AndrewPardoe Are you following my list from https://developercommunity.visualstudio.com/content/problem/35325/missing-vs150comntools.html?

[AndrewPardoe]

@refack I wasn't, but I'm searching for all the places online where vswhere was mentioned and trying to link to this post : ) Thank you for the list!