[question] VS 2022 v17.10.4 Error: Toolset directory for version '14.3' was not found.

[jmoutray]

What is your question?

I have VS 2015 project files, using conan.tools.microsoft generators/builders and setting compiler.toolset=v143,
$(PlatformToolset) = v143, but $(PlatformToolsetVersion) = 140 (wrong).

I have conan v1.59.0 and VS 2022 v17.9.0 installed.

Running on another machine with conan v1.59.0 and VS 2022 v17.9.6, $(PlatformToolsetVersion) = 143 (correct).

I updated my VS 2022 from v17.9.0 to v17.10.4 and now I am seeing this error:

xxxxxx/x.x.x@xxx/xxxx: Calling build()
**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.10.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[ERROR:vcvars.bat] Toolset directory for version '14.3' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[jmoutray]

Looks like I see similar issue at #16239.

[memsharded]

Hi @jmoutray

Thanks for your question.

This is expected, Conan 1 did not update to provision for the latest VS 17.10 update that changed the versioning approach, only Conan 2 did implement the necessary changes to support VS 17.10 (with 14.4 toolset version, v143 platform toolset).

I am afraid this is not planned to be fixed in Conan 1, because Conan 1 uses the Visual Studio IDE versioning, not the compiler or the toolset version, which means there is not enough information to define the toolset version correctly.

[jmoutray]

Thanks for the response.

(Just to clarify: above I said $(PlatformToolsetVersion) = 143 (correct) for VS 2002 v17.9.6, but that was NOT correct. I did not have VS 2015 (IDE or build tools) on that machine, which was the reason for this.)

[jmoutray]

Update: I tried using conan 2 and I learned a couple things:

conan.tools.microsoft.MSBuildToolChain (conan 1 and 2) sets $(PlatformToolset) using a .props file containing

  <PropertyGroup Label="Configuration">
    <PlatformToolset>v143</PlatformToolset>
  </PropertyGroup>

This property assignment appears to work but does not propagate to the VS macro $(PlatformToolsetVersion).

However, and more concerning, adding #pragma message ("_MSC_VER: " _CRT_STRINGIZE(_MSC_VER)) to source code reveals _MSC_VER: 1900, even when using compiler.toolset=v143 (conan 1) or compiler.version=193 (conan 2).

The original conan 1 MSBuild helper launches msbuild.exe with the /p:PlatformToolset=v143 argument, which does affect $(PlatformToolsetVersion), and shows _MSC_VER: 1939.

Therefore, I feel like I am not able to use the VS 2015 .vcxproj files, and build for the v143 platform toolset using conan.tools.microsoft helpers.

[memsharded]

Hi @jmoutray

We have some tests in the suite like:

conan/test/functional/toolchains/microsoft/test_v2_msbuild_template.py

Line 38 in 0b5860e

def test_msbuild_lib_2022():

This test will be using different -s compiler.version=19X and the resulting output will be containing the right _MSC_VER19X matching version.

It would be good to have a fully reproducible case. The tests are using the template

conan new msbuild_lib -d name=hello -d version=0.1

to try things. If you could please try to it, and provide the full output of the later conan create command, that would really help.
If I do:

conan create . -s compiler.version=191 -c tools.microsoft.msbuild:vs_version=15

Then I get the expected mypkg/0.1: _MSC_VER1916

[jmoutray]

Here's the rub...

My .vcxproj has <PlatformToolset>v140</PlatformToolset> for each Configuration|Platform, whereas hello.vcxproj does not.
My .vcxproj has <Import Project="conan\conantoolchain.props" /> for each Configuration|Platform, whereas hello.vcxproj has one with no Condition attribute.

If I remove the <PlatformToolset> from my project, I see error MSB8020: The build tools for v143 (Platform Toolset = 'v143') cannot be found.
If I then remove the <Import> from each Configuration|Platform and create a single <Import> with no Condition, I can build v143 successfully.

However, two points:

1. When adding existing property sheets via the Property Manager, VS adds the <Import> element to the individual Configuration|Platforms.
2. More importantly, when using the global <Import>, strange behavior occurs with environment variables in debug sessions. Basically, defined environment variables do not get set in the shell as defined in the Debug properties. I originally started with a single <Import> until I experienced this, and reverted to the way VS Property Manager adds the property sheets to the file.

For now, I can configure my .vcxproj file similar to the hello.vcxproj, and deal with the debugging issue. And I quickly attempted to duplicate this problem and was unable to; therefore, it may have been an issue with VS 2015 and not so with VS 2022.

[memsharded]

Thanks very much for the feedback @jmoutray

If this happens again in more modern VS versions, please feel free to re-open or create a new ticket, maybe we can have a look to try to improve somehow the integration or at least the docs for this.