Conan: Conan not detecting "clean" installation of VS 2017

[ghost]

Hi everyone,

After setting up VS 2017 without the older SDKs or build tools and trying to execute conan v0.22.1 for the first time (with the devenv environment variables initialised of cource) I get this message (there is no problem if the VS 2015 build system or VS 2015 itself has been installed on the machine at the same time):

It seems to be the first time you've ran conan
Auto detecting your dev setup to initialize conan.conf
ERROR: Unable to find a working compiler
Default conan.conf settings
        os=Windows
        arch=x86_64
        build_type=Release
*** You can change them in ~/.conan/conan.conf ***
*** Or override with -s compiler='other' -s ...s***

CMake does detect my compiler as "Visual Studio 15 2017".

Is there a workaround for this or a fix planned in an upcoming release?

[memsharded]

There is a problem with VS2017, they have removed the support for vs150comntools, which is used to detect it. Current detection of VS2017 is a nightmare, with Powershell functions, or a vswhere application that has to be retrieved from somewhere else.

Conan can't do anything reasonable with this scenario, so until it is not improved by VS, there is little to do.
The current solution is to define the vs150comntools environment variable in your system after installing VS2017, then conan will detect it. Or just type it manually in conan.conf.

[ghost]

Well, still good then! I thought it was going to be more complicated than that.

[jacmoe]

I am not a Windows and neither a Visual Studio user, and am having problems with this. (VirtualBox)

Did you set the VS150COMNTOOLS environment variable ?

Or just edited conan.conf ?

Can I see a sample conan.conf, please? :)

Even when I used to be a Windows using Visual Studio user, every time VS was updated, they changed the directory layout, which is confusing (even to native Windows users ..)

[ghost]

To my understanding Visual Studio used to set the VSxxxCOMNTOOLS variable before, and conan (and other tools) could rely on it. For some reason that escapes me, VS has just stopped doing this in version 2017, so we need to either set an environment variable or execute this before running our builds:

set vs150comntools=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\

If conan has already been executed on your system before this variable was set, it may be missing the highlighted lines below at the bottom, so you need to add them manually, like this if you want them the way conan would do it in previous VS versions by default:

[settings_defaults]

arch=x86_64
build_type=Release
os=Windows
compiler=Visual Studio
compiler.version=15
compiler.runtime=MD

... or like this, also changing arch, if you want to be able to just run conan install, cmake and cmake build on the command line for your project without the cmake -G flag and the cmake build --config flag (I mention them here for example), which are needed not because of a conan issue but because of VS's quirks.

[settings_defaults]

arch=x86
build_type=Debug
os=Windows
compiler=Visual Studio
compiler.version=15
compiler.runtime=MDd <---- Attention MD becomes MDd

Of course, if you don't mind being verbose, here's an example of how you can skip all of that about conan.conf (still needing VS150COMNTOOLS though) and build a project while specifying everything on the command line:

mkdir build
cd build
conan install .. -s arch=x86_64 -s build_type=Debug -s os=Windows -s compiler="Visual Studio" -s compiler.version=15 -s compiler.runtime=MDd --build missing
cmake -G"Visual Studio 15 2017 Win64" ..
cmake --build . --config Debug

[ghost]

While we're on this subject, and to distribute knowledge that I acquired after much pain and suffering, I would suggest that you also open your Visual Studio 2017 Installer and make sure that the Windows 8.1 SDK is installed in addition to the Windows 10 SDK:

When building existing old VS projects, many times the referenced Windows SDK fails to be upgraded to v10 and just gets stuck at v8.1. This can happen even when upgrading from the interface of Visual Studio. Obviously, I have no idea why. For your own projects of course I guess you will make sure you are using the right SDK, setting it by hand, but when your scripts execute, downloading and automatically upgrading dependencies this will save you some time and brain cells murdered by extreme frustration.

[jacmoe]

Thanks a bunch! 😄
Yes, I definitely want to preserve what's left of my precious brain cells! :p
I will install the 8.1 SDK.

And thanks a lot for the sample conan.conf, that really helps!

[ghost]

You're welcome! About the SDK, you may be wondering why I do this and not just explicitly set the Windows SDK version when running msbuild or cmake. There are 2 reasons:

• I've had cases when even setting the SDK via the graphical interface while upgrading a project didn't do it.
• While the version string for previous sdks was something like "v8.1", someone at Redmond recently decided that v10 should be named things like "v10.243526234623" or "v10.562345345789", which can change at any update. Maybe there's a command to detect this, but I'd rather spend my time learning Vulkan or astrophysics even, instead of the VS command line language which will change again in an unpredictable manner in a couple of years.

There you go Luke. I have now transmitted everything I know about the Force to you. Use this knowledge wisely, until VS 2019, which will deprecate it.

[jacmoe]

I still remember all the hoops that I had to jump through to manage 2003/2013/2015 and Professional/Express, DirectX SDK and Windows SDK - fun times! 😸

One of the reasons why I switched to CMake years ago!
(( And Linux !! ))

[ghost]

😆 And, as you see, even there MS has figured out how to mess it up for us. It is my personal conviction that Windows builds are a bottomless attention pit and the reason we still haven't found a cure for cancer or colonised Mars.

[memsharded]

Hi all!

@jacmoe regarding the MD/MDd runtime, instead of changing the [settings_defaults] in conan.conf, I strongly suggest using the profiles feature, much more powerful, versatile, and you can share profiles just putting them inside a repo.

Thanks @dimi309 for the help! Very good tips!
Instead of setting in the command line, I typically define it in the system (Control Panel->etc, etc), and I forget about it.
In Appveyor, I just set it in the appveyor.yml script.

[ghost]

Note to self: learn about conan profiles 👓