Visual Studio minimum version and settings support

[memsharded]

Conan 2.0 will implement Visual Studio compiler support via the msvc compiler setting, that will use the compiler version instead of the IDE version. The legacy Visual Studio compiler setting will be dropped.

The built-in build system integration to Visual Studio, provided by from conan.tools.microsoft (MSBuildDeps, etc), will provide full support down to Visual Studio 2017 (15, toolset v150), and partial support to Visual Studio toolset v140 from Visual Studio 2017 and above (but not from the Visual Studio 2015 IDE).

---

• 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.

[michaelmaguire]

We will be broken by this change. Big ships take a while to turn...

[memsharded]

Hi @michaelmaguire Can you please be a bit more specific about this:

We will be broken by this change

What will exactly be broken? All the tools to migrate are already available in Conan 1.45, and the path to update is defined in the proposal, what would be the main blockers?

[michaelmaguire]

Hi @michaelmaguire Can you please be a bit more specific about this:

We will be broken by this change

What will exactly be broken? All the tools to migrate are already available in Conan 1.45, and the path to update is defined in the proposal, what would be the main blockers?

Researching and applying migration will require scheduling work items across multiple teams.

[memsharded]

Researching and applying migration will require scheduling work items across multiple teams.

Ok, I understand that, but that doesn't mean this will be a 2.0 breaking change, just that it will require a considerable effort to migrate to that.

I believe that with the Conan 1.X binary compatibility fallback msvc -> Visual Studio, the major effort to be done is to move to the new build system integrations (CMakeDeps, MSBuildDeps, etc). Once that happen, starting to build with msvc profiles can be done gradually, because if binaries not existing, it will fallback to previous Visual Studio binaries. All of this can happen in Conan 1.X, and from there, the upgrade to 2.0 should be smooth and not breaking.

[puetzk]

Linking previous discussion of minimum MSVC version: #5

I don't have any particular objection (we're mostly in the middle of the VS2019->2022 transition), but I am a little surprised the bar is being set so recent: CMake still supports everything using (Visual Studio 2012+), and also Visual Studio 10 2010 (though this was recently deprecated in 3.20) and even .vcproj (Visual Studio 9 2008).

And toolset multi-targeting supports back to Visual studio v90 toolset (Visual Studio 2008). So if CMake supports cmake --build with these generators, and msbuild supports multi-targeting for https://docs.conan.io/en/latest/reference/conanfile/tools/microsoft.html#msbuild to use, it's not real clear to me what about conan would need to do differently to support toolsets back to v90.

Just "not supported" in the sense that nobody is testing them, and maybe not listed in the settings.yml?

[memsharded]

CMake still supports everything using (Visual Studio 2012+), and also Visual Studio 10 2010 (though this was recently deprecated in 3.20) and even .vcproj (Visual Studio 9 2008).

Support via CMake wouldn't be a big issue, but we also need to support the native MSBuildDeps, MSBuildToolchain integrations, that are provided via xml .props properties files, and that might have subtle differences that we would need to take into account.

The minimum CMake supported is 3.15, which is from 2019, using a time based approach, it seems supporting VS from 2015 would be a reasonable time frame. In any case, this is the reason this proposal is here, if there are people stuck in older VS versions, it is expected that they would raise their concerns, and this could be changed. From what we are seeing talking to users is that since the community editions and when Msft started to really catch up on the standards, the upgrades to recent VS versions has been much faster than it used to be.

And toolset multi-targeting supports back to Visual studio v90 toolset (Visual Studio 2008). So if CMake supports cmake --build with these generators, and msbuild supports multi-targeting for

Yes, with toolsets is possible to go to previous versions, easier than using previous IDE versions. This is the reason we are proposing support for v140, but not for VS2015 IDE.

Just "not supported" in the sense that nobody is testing them, and maybe not listed in the settings.yml?

Yes, that is the idea. Testing with even older versions is a lot of effort too. It is possible that things work with previous versions, and maybe by adding older settings.yml things might work. It won't be a problem to add fixes provided by users for previous versions as long as they don't suppose a risk for the modern versions and it is not a big liability of future development and maintenance.

[tonka3000]

Hi,

For me this could be a showstopper for 2.0. Right now I need to support VS 2012, 2015 and 2017. Hopefully I can drop support this year for at least VS 2012. The main problem is that me and my team need to integrate into a lot of big applications which are closed source and require often older compiler versions.

I tried toolset multi-targeting in the past. I could not remember every detail but it was very painful to get things to work.

Yes, with toolsets is possible to go to previous versions, easier than using previous IDE versions. This is the reason we are proposing support for v140, but not for VS2015 IDE.

So defining a older toolset would search for the older compiler? Do I need VS 2017 always to get back to 2012 and 2015 corresponding toolset?

[memsharded]

So defining a older toolset would search for the older compiler? Do I need VS 2017 always to get back to 2012 and 2015 corresponding toolset?

@tonka3000 yes, this is the idea, but if it is going to be a blocker, lets talk.

For me this could be a showstopper for 2.0. Right now I need to support VS 2012, 2015 and 2017. Hopefully I can drop support this year for at least VS 2012. The main problem is that me and my team need to integrate into a lot of big applications which are closed source and require often older compiler versions.

I think VS 2015 might be more doable, up to my knowledge, VS2015 is relatively similar to VS2017, while VS 2012 might be a bit more challenging.

Can you clarify if you are using native VS, or are you using CMake generated solutions? Also, as the tooling is already there in 1.45, we have time to experiment with it. Have you already tried the new integrations? Maybe it is worth to open a parallel thread to try things, to not pollute this thread too much with experiment details, and then come back here with our findings. Do you want to file an issue (for the Conan repo, we can assign a look-into for next 1.46 release) and we can check there?

[tonka3000]

Parallel thread see conan-io/conan#10610

[datalogics-kam]

We have a cluster of projects that will need to support compiler.version=12, which is Visual Studio 2013. Because this is a product that we build for external consumption, it's unlikely that we will be able to change the compiler version.

We don't actually use Conan to run the build for that project, but we do consume Conan-generated .props files for part of it, and the SCons generator for other parts.

[MarcelRaad]

I'm fine with dropping old versions, but what blocks me from using the msvc compiler for everything is that non-default toolsets, like v141_xp, v141_clang_c2, and ClangCL, are not supported anymore.

[memsharded]

I'm fine with dropping old versions, but what blocks me from using the msvc compiler for everything is that non-default toolsets, like v141_xp, v141_clang_c2, and ClangCL, are not supported anymore.

that is fair @MarcelRaad, it is very likely that some of these needs to be added to the new msvc compiler. They are not there because they have not been requested so far, but it makes sense to add them. The xp one would probably totally make sense, though the clang ones we need to check. It is possible that they are implemented via a compiler=clang setting, with something like a tools.cmake.cmaketoolchain:generator="Visual Studio 16", you can see this snippet from the CMakeToolchain:

        elif compiler == "clang":
            if generator and "Visual" in generator:
                if "Visual Studio 16" in generator:
                    return "ClangCL"
                else:
                    raise ConanException("CMakeToolchain compiler=clang only supported VS 16")

If you can report specifically which toolsets you need, and a bit of context (as a regular issue for Conan 1.X releases, this needs to be implemented before 2.0, so you can change in 1.X scope)

[memsharded]

We are working in conan-io/conan#10808 to provide better support for msvc missing pieces, including older versions and toolsets.

Lets update the proposal, I'd like to suggest the following:

• Having tested support down for VS2017, both for CMake and native MSBuild
• Implementing "best-effort" support down to VS2015 for native MSBuild and down to VS2012 via CMake. This support won't be possible to be tested in CI, and will rely on contributors and external testers for validation, but it will be built-in, documented, and "stable" (as it won't be removed/dropped).
• Integration will support toolsets too. Though some of the clang/llvm might be treated as a clang compiler setting, that needs to be investigated.

With these considerations, will anyone of the above change the vote?

Regarding the migration effort from "Visual Studio" => "msvc", we know it can take time and work. But keeping both settings in 2.0 we strongly believe that it will only add confusion and issues (bugs, inconsistencies), and with the above considerations there aren't apparently real blockers to not remove Visual Studio setting in 2.0.

[michaelmaguire]

We are working in conan-io/conan#10808 to provide better support for msvc missing pieces, including older versions and toolsets.

Lets update the proposal, I'd like to suggest the following:

• Having tested support down for VS2017, both for CMake and native MSBuild
• Implementing "best-effort" support down to VS2015 for native MSBuild and down to VS2012 via CMake. This support won't be possible to be tested in CI, and will rely on contributors and external testers for validation, but it will be built-in, documented, and "stable" (as it won't be removed/dropped).
• Integration will support toolsets too. Though some of the clang/llvm might be treated as a clang compiler setting, that needs to be investigated.

With these considerations, will anyone of the above change the vote?

Regarding the migration effort from "Visual Studio" => "msvc", we know it can take time and work. But keeping both settings in 2.0 we strongly believe that it will only add confusion and issues (bugs, inconsistencies), and with the above considerations there aren't apparently real blockers to not remove Visual Studio setting in 2.0.

This would be much appreciated. I've changed my vote to thumbs up.

[tonka3000]

I checked 2d67de9a089716e18b6a1c7054a2b807f41af074 of the conan develop branch and it worked (details see conan-io/conan#10610 (comment))

I've remove my downvote. Also conan-cmake script can be adopted to match the old behavior with the msvc generator in my opinion.

Regarding the migration effort from "Visual Studio" => "msvc", we know it can take time and work. But keeping both settings in 2.0 we strongly believe that it will only add confusion and issues (bugs, inconsistencies), and with the above considerations there aren't apparently real blockers to not remove Visual Studio setting in 2.0.

I agree on that point.

[memsharded]

The proposal has been updated according to the reviews. Please check 962cf75.

conan-io/conan#10808 has been merged and seems to be working fine, so apparently there shouldn't be blockers for this proposal. If there is no other major concerns, we will finally approve it and merge it soon.

[datalogics-kam]

I believe I have support for updating the version of Visual Studio we use on some older projects if/when it comes to that, so I changed my vote to "Approve."

[Croydon]

Information about VS 2022 seems to be missing from the doc

[memsharded]

Information about VS 2022 seems to be missing from the doc

The document is only talking about "minimum" (older versions) requirement, it is assumed that support for newer versions will continuously be added as usual.

[memsharded]

Thanks for all the feedback, and specially to the members testing things and older VS versions in their systems.

Seems this is fine to be merged.