Visual Studio 2017

[emberian]

https://github.com/alexcrichton/gcc-rs/blob/master/src/windows_registry.rs#L120 needs to be updated to look for whatever the version number for VS2017 is (16.0?)

[luser]

@retep998 was talking about this on #rust-internals not long ago, apparently Microsoft changed things again so the registry method doesn't work. The officially supported way to locate the MSVC 2017 install is by calling a bunch of COM APIs.

There's a Microsoft blog post with more information.

[retep998]

I have VS 2017 code in https://github.com/retep998/msvc-bunny. Once it gets support for detecting all msvc versions with an actual API and has a proper name, gcc can be switched to using it.

[alexcrichton]

Awesome, thanks @retep998! Is there anything I can do to help that out?

[retep998]

@alexcrichton The biggest struggle with that crate is not the functionality itself, but figuring out how to emit warnings and diagnostics to the user regarding their msvc installation (or lack of one). Help in designing the API would be appreciated.

[alexcrichton]

@retep998 Wouldn't warnings/diagnostics be part of how the compiler and/or gcc consume this API? That is, not so much an API question or library question for the crate you're working on?

It looks like right now the bindings are mostly the raw COM api methods and whatnot, is that right? If so that seems reasonable to me but did you have specific other aspects you were up in the air about?

[retep998]

@alexcrichton Basically, I want rustc to be able to print out various diagnostics such as "Successfully located VC++ 14 but failed to locate a valid installation of the Windows SDK", or "No VC++ installation found. The only link.exe in your PATH is from MinGW which will now fail". Basically the question is how should the crate expose this information so consumers like rustc and gcc and rustup can print out these relevant diagnostics.

[alexcrichton]

Hm ok. I suspect detection of previous installations won't be changing, right? In that sense all the code is already written (what's in the compiler/gcc-rs right now), I think?

In that sense is this just a question of how to do this for Visual Studio 2017?

[retep998]

@alexcrichton I'd like to do these advanced diagnostics for all versions. The actual logic of finding installations is already written in rustc and gcc and can be copied over with a bit of modification, but how to report failure is something I really want to improve on across the board.

[alexcrichton]

Oh I just figured there'd be a customized routine for basically every VS version known. That way when you want to find a VS version you just attempt to find all of them, returning an error if all of them return an error or success if any of them succeed?

[whoisj]

Oh I just figured there'd be a customized routine for basically every VS version known. That way when you want to find a VS version you just attempt to find all of them, returning an error if all of them return an error or success if any of them succeed?

The vswhere utility provide this functionality. I don't see why rust core tools couldn't package it and redist it, at least on Windows; the MIT license is fairly permissive.

[retep998]

@whoisj The kind of problem I'm trying to solve is "What do I do when the user only partially installed VC++ and is missing part of it, such as the Windows SDK?". If I just ask vswhere and it says nope, what am I going to tell the user? If I myself do all the hard work of finding VC++ then I know exactly why I failed to get a complete toolchain and I can tell the user. The hard part isn't finding VC++, it is reporting misconfigured environments to the user.

[whoisj]

@retep998 I agree, but the vswhere application already understands how to query for various SDKs published by Microsoft. Using it avoids attempting to duplicate and maintain functionality already provided by Microsoft.

As you can see from the help spew, it'll filter data via the -requires option.

Visual Studio Locator version 1.0.62
Copyright (C) Microsoft Corporation. All rights reserved.

Usage: vswhere.exe [options]

Options:
  -all           Finds all instances regardless if they are complete.
  -products arg  One or more products to find. Defaults to Community, Professional, and Enterprise.
                 Specify "*" by itself to search all product instances installed.
  -requires arg  One or more workloads or components required when finding instances.
  -version arg   A version range for instances to find. Example: [15.0,16.0) will find versions 15.*.
  -latest        Return only the newest version and last installed.
  -legacy        Also searches Visual Studio 2015 and older products. Information is limited.
                 This option cannot be used with either -products or -requires.
  -format arg    Return information about instances found in a format described below.
  -property arg  The name of a property to return. Defaults to "value" format.
  -nologo        Do not show logo information. Some formats noted below will not show a logo anyway.
  -?, -h, -help  Display this help message.

Formats:
  json           An array of JSON objects for each instance (no logo).
  text           Colon-delimited properties in separate blocks for each instance (default).
  value          A single property specified by the -property parameter (no logo).
  xml            An XML data set containing instances (no logo).

Additionally, there's no reason it cannot be improved to find additional Microsoft SDKs not installed by Visual Studio.

[retep998]

@whoisj Have you actually looked at the data that vswhere spits out versus the data rustc needs to actually link stuff? The only bit of useful information it provides is where VS is installed. Finding VS isn't very hard: for the older versions it is just looking up a simple registry key, although for the newer versions it is a rather massive blob of COM, but I already wrote that code and it works. Guess what vswhere doesn't do? It doesn't tell me where the Windows SDK is, where the Universal CRT is, where everything actually is inside a given VS installation.

In fact, for VS 2015 and older rustc doesn't actually care where VS is. The closest thing it does do is find where VC is (https://github.com/rust-lang/rust/blob/master/src/librustc_trans/back/msvc/mod.rs#L179-L184), and beyond that the rest of the code there cannot be replaced by shelling out to vswhere.