[tools] Visual Studio 2017 (15.2) required

[jgsogo]

Visual Studio 2017 (15.2) was released on May 2017. This version allows to install side-by-side different versions of the MSVC toolset, it allows you to build binaries that are fully compatible with the ones built using older versions.

Visual Studio 2017 (15.2) includes wswhere application. This tool is needed Conan to locate Visual Studio installation and toolsets available (link to proposal required).

---

• Upvote 👍 or downvote 👎 to show acceptance or not to the proposal (other reactions will be ignored)
  • Please, use 👀 to acknowledge you've read it, but it doesn't affect your workflow
• Comment and reviews to suggest changes to all (or part) of the proposal.

[jpovedano]

Extended EOL of VS2012 ends on January 2023 (https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing)

Producing VS2012 compatible binaries will require to have VS 2017 or newer also installed in the machine. Given the size of the installation of Visual Studio, this might not be an option to some enviroments (build machines becomming too heavy).

[a4z]

I would like to fix that typo here, wswhere -> vswhere
but the repo jgsogo:proposal does not exist (for me) , so I do not know how or where to submit the pr for the pr :-)

[jgsogo]

Now the repository should be public

[jasal82]

If the reason for this minimum requirement is solely that the vswhere tool is available for locating the installations I'm fine with it. Targeting toolsets < VS2017 must still be possible, however.

Producing VS2012 compatible binaries will require to have VS 2017 or newer also installed in the machine. Given the size of the installation of Visual Studio, this might not be an option to some enviroments (build machines becomming too heavy).

We're using the lightweight build tools VS installations in our Windows docker containers which are provided as packages in Chocolatey. Not sure whether these are official distributions though.

[puetzk]

Conan migth need Visual Studio 2017 (15.2) installed, but it can target older versions (vswhere is able to find older installations too).

If this is truly just about the build helpers using vswhere, I would definitely have a preference for limiting the requirement to just that. I have conan-packaged legacy binaries from as far back as VS2005 (albeit usually as Packaging Pre-built Binaries, not having conan build from source), just for the sake of being able to assembly pretty much any combination I might want in a common way of declaring what is needed.

For bonus points, just package vswhere on conan-center-index or otherwise bundle it: it's not actually a part of visual studio at all, it's a distinct single-file executable with its own releases (https://github.com/microsoft/vswhere/releases/latest), and it's MIT licensed (https://github.com/microsoft/vswhere/blob/develop/LICENSE.txt)

[puetzk]

Visual Studio 2017 (15.2) includes wswhere application. This tool is needed Conan to locate Visual Studio installation and toolsets available (link to proposal required).

Producing VS2012 compatible binaries will require to have VS 2017 or newer also installed in the machine. Given the size of the installation of Visual Studio, this might not be an option to some enviroments (build machines becomming too heavy).

Just to be pedantic, it's actually the Visual Studio installer / maintenance tool that bundles (some version of) vswhere. And that's its own "installed" tool in Programs and Features. So you wouldn't actually have to even install VS2017, you'd only have to launch it's installer as if you were thinking about doing so.

[michaelmaguire]

My company is still heavily invested in vs2015 toolchains and this minimum requirement would impact us.

[davidtazy]

I do not agree,
The lowest version of its dependancies conan will support, the more new users u can have
recent version of dependancies is good for conan developpers , it is bad for user community.

I think there is a lot of teams stuck with older version of visual studio but I could not find any survey of visual studio usage.

[a4z]

The lowest version of its dependancies conan will support, the more new users u can have
recent version of dependancies is good for conan developers , it is bad for user community.

except, when support of old versions hinder progress and development of new features and improvements or binds developer resources that will be missed on other places.

in general, It is always that when (new) minimum versions will be set (no matter if it is for this project or an other one), there will be some users that are extreme unhappy. And they will argue that it is important to support the old version. While in reality it might not be that important in general, but a burden.

cutting old version can also be a chance for projects to find arguments to move forward, at the end something every project should do anyway

[prince-chrismc]

This is exactly how we expect our development teams to work. They typically work from the latest version but are still required to support VS2013.

[puetzk]

My company is still heavily invested in vs2015 toolchains and this minimum requirement would impact us.

Do youmean that in a "we cannot install anything from the last 5 years" sense, or in a "we still need to use the v140 toolset" sense? It seems the latter would be fine, you can install the v140 toolset using the VS2017/2019 installer and you'll have vswhere, msbuild 16.0, etc - just using the older compiler and libs. You can also multitarget the native toolsets as far back as v90 (VS2008), though you actually have to install the full old IDE to get those toolsets, MS doesn't have just the compilers/libs packaged as a checkbox to be installed through the modern Visual Studio Installer like they do for v140 and up

[KerstinKeller]

I would like to point out, that it would be beneficial, if Conan actually only requires that VS build tools are installed, instead of a full blown VS install.

While most developers have a VS installation, build machines don't necessarily have to.

I am not familiar how Conan triggers builds of VS solutions (msbuild vs vcvars.bat), because we mainly use CMake, but I remember running into the strangest behavior on different build machines, trying to build the Python C++ extensions, which (for Windows) are based on Visual Studio projects, targeting different Visual Studio Versions, based on the Python version.

[michaelmaguire]

It seems the latter would be fine, you can install the v140 toolset using the VS2017/2019 installer and you'll have vswhere

In theory this should work. In practice we have still seen issues with attempting that approach.

We could not move forward with vs2017 because it had a bad crash with C++ compiler version 19.16.27032.1 that affected us until it was patched this year with https://docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes#15.9.19, so that set us back in terms evolving our SDLC. Our plan was to wait for vs2019 which we will get to but we will still be on vs2015 for a while.

[kenfred]

Another data-point here: a large company I've worked with has mandated VS2015. It would be interesting to see a survey of VS version usage to get a broad picture. Conan would benefit from greater adoption within enterprise organizations. Unfortunately, such groups usually have piles of legacy code and are slow to upgrade tooling.

It has been pointed out in this thread that the a min Visual Studio version of VS2017 doesn't mean you can't use older toolsets. That is persuasive. However, the Visual Studio version is found within the default settings.yml and is hashed as part of the package ID¹. Perhaps Conan 2.0 should remove Visual Studio version from the default settings if it truly doesn't affect the binary-compatibility of packages.

¹Of course, individual packages can define which settings they care about and how the package ID is created, but in practice I think most packages don't bother to override these things. Once again, I don't have data to support this assertion. :)

[puetzk]

if it truly doesn't affect the binary-compatibility of packages

Conan supports being stricter, but (since 0.29) conan defaults to using self.info.vs_toolset_compatible(). So if you compile with

compiler="Visual Studio"
compiler.version=15
compiler.toolset=v140

you get the same package_id as if you had used

compiler="Visual Studio"
compiler.version=14

i.e. it assumes that compiler.version should in fact reflect the compiler used, not the version of the IDE/msbuild/etc.
The profile specifies both, since conan does need to know which msbuild, or vcvarsall to use, but it's assumed not to have affected the resulting binaries.

[puetzk]

But I think we're still circling the big unknown: was this proposal motivated by wanting to let tools.vcvars_* rely on vswhere, or by wanting to have at least msbuild >= 15.0 msbuild (so you'd need quite a bit of extra disk), or is it really about cl.exe >= 19.10 (the most problematic, since that changes the final binaries)? I'm sure they at least in part wanted to see where the discussion took us, since there are really 3 distinct questions it would be nice to know more about the motive...

[kenfred]

was this proposal motivated by wanting to let tools.vcvars_* rely on vswhere, or by wanting to have at least msbuild >= 15.0 msbuild, or is it really about cl.exe >= 19.10

@puetzk That's a good summary of the considerations!

Given that the proposal mentions "build binaries that are fully compatible with the ones built using older versions", I think we can cross out the last one as a motivating factor. We know that this proposal expressly intends to maintain support for older toolsets.

You also have brought to my attention that Conan has already put a stake in the ground regarding msbuild and vcvarsall. It seems that Conan will assume packages to be identical when built by the same toolset, regardless of the build environment. Assuming the teams wants to carry this convention through to Conan 2.0, then I think we can cross the second one off the list as well.

Therefore we're left with the motivation which was explicitly stated in the proposal itself - they want VS2017 because it plays nicely across toolsets and remains backward compatible.

If all of my logic here is correct, then I restate my suggestion that Conan 2.0 settings should not include the Visual Studio version and only the toolset is required (proceeding with the assumption that different versions of msbuild and vcvarsall should not change the resulting binary).

[DoDoENT]

I absolutely don't agree with this proposal.

It limits users to a fairly recent version of VS. Furthermore, I think that Conan should not treat Visual Studio as the compiler. Visual Studio is an IDE - a combination of a code editor, debugger and MSVC toolchain (you don't have to use it, you can use other toolchains with Visual Studio's editor and debugger as well). Therefore, conan should treat MSVC as compiler, just like it treats GCC, ICC and Clang.

This would also remove the need for having "toolsets" in "visual studio" "compiler" and possibly even the need for vswhere utility. In general, conan could ship with pre-configured "toolchains" for different MSVC versions. Since there is a proposal for toolchains (I need to put that into RFC format, but feel free to read the linked comment), it should be possible to ship toolchains for specific MSVC versions with either conan or as conan packages. Generally, one possibility could be to basically pack the entire toolchain into conan package and distribute that (just like android NDK or emscripten SDK).

However, if this is problematic from a legal point of view (MSVC EULA etc.), another possibility is to simply have a toolchain conan package that needs to be configured with paths to compilers, MSBuild and everything else that is required for building. Users and companies could then use conan profiles to define the locations of the toolchain where it's expected to be installed (these would be a simple conan package options). Furthermore, for toolchains for MSVC 19.10 (default in VS 2017 15.2) and newer, the vswhere utility could be used to default-initialize the installation locations, but those could be always overwritten by profiles and command-line options.

Also, please take a look at my solution for MSVC compiler version handling, which works flawlessly in our CI and developer environments. Unfortunately, it's not a general solution, as this does require some architectural changes in conan, you can also see my suggestions for those changes in conan there as well.

[memsharded]

To clarify: we don't plan to remove the ability of users to use their own tools like CMake or Visual Studio, installed in their system in the way they like. We might provide other useful ways to install them, as with Conan packages, build_requires, or even new features, but removing the ability of users to provide their own tools directly themselves, is not under consideration. The current proposal applies mainly for this case, as for other cases as using build_requires, is not relevant.

Things like relying on a ConanCenter package that bundles vswhere is not a possibility, users should be able to use their Visual Studio toolchain they installed in their system without ever connecting to ConanCenter, Visual Studio support of supported versions should be completely built-in.

[KerstinKeller]

So first things first: we are still using VS 2015 in a lot of projects and many engineers still only have that version of VS installed on their machines. Unlike the Python or CMake minimum version discussion, an mandatory update is connected with licensing costs. It will be hard to argue that everyone needs to update, just because Conan requires it.

So maybe it's necessary to understand a bit about Conan architecture to understand the implications, because first I thought this doesn't affect us, because we're using the CMake generator anyways. So in what cases does this PR affect me:

• Does this affect only users using the Visual Studio generator?
• Does this affect me, when I use the CMake generator, but configure to build for v140 as by the settings?
• Does it affect me when I rely on Conan 'tools' (helpers) to manually build a 'project.sln' (for VS 2015) file from the 'build' function?

I don't care about the first case, but about the second and third one.

Locating and triggering VS builds is not straightforward in all cases, but CMake seems to have found a way to do it somewhat robustly, even if only the build tools for the respective version are installed.

And I agree with @DoDoENT that after all VS is an IDE, so the compiler relevant part is the toolset, while the actual VS version is relevant for the invokation of Conan / CMake generators.

[jgsogo]

Hi! We've read very good arguments around this proposal. We have decided to postpone this decision until we have better knowledge about what is needed by future Conan and what will be the requirements. This investigation will (probably) be done related to a new compiler to be proposed (read here: conan-io/conan#3573). We need to define the minimum tools required by Conan to be used in Windows/MSBuild environments, but maybe the answer is not the whole IDE.

Thanks a lot for your comments, it's been really valuable feedback. We will come back with more Windows-related proposals.

[jcar87]

From my past experience with VS, I largely agree with @KerstinKeller's comments about licensing. I'm not entirely familiar with the different licensing options offered by Microsoft for Visual Studio, but I believe it's not uncommon to be stuck on earlier versions of VS if the license is perpetual and tied to a specific version.

On the other hand, from what I remember, vswhere.exe is not strictly part of VS 2017, but part of the installer, as @puetzk mentions. If "installing the installer" is valid/permissible licensing wise (and considering that vswhere itself is open source with an MIT license), then maybe this could be a valid workaround to cover the case of vs2015 + vswhere?

Perhaps .. in the same way that vswhere is currently published to chocolatey, I wonder if it will eventually make it to winget -> see microsoft/vswhere#222

Something like winget install vswhere seems simple enough of a requirement, once the windows package manager is widely available...

[memsharded]

Regarding the proposal of msvc to replace the Visual Studio setting, that was introduced as experimental some time ago in Conan 1.X. Now conan-io/conan#10057, proposes to change it, as the model seemed to be flawed regarding version comparison. Feedback welcome (the idea is that the msvc becomes stable in 1.X to be able to use it and have a smooth transition to Conan 2.0, that will remove the Visual Studio setting.