17
votes

In the olden days when developing a C++ project on Windows in Visual Studio, your Visual Studio version would have its own version of the C and C++ libraries, and your project would reference a specific version of the Windows SDK in order to access headers for access to the Win32 platform. If you had multiple versions of the Windows SDK installed there was a complicated system involving environment variables that enabled you to select which version of the Windows SDK Visual Studio would use by default.

It wasn't great, and getting it to work properly required a bit of digging around, but it did just about work.

Having just upgraded from VS2012 to VS2015 and it seems to me that whatever this system has been replaced with is either downright broken, or I'm just not understanding it.

  1. Upgrading a simple VS2012 C++ console app that includes conio.h to VS2015 breaks with no error reported. Why? conio.h is no longer in the Visual Studio C/C++ libraries and instead now lives in Windows Kit 10, upgrading the project doesn't reseat the SDK used (as you would expect).

  2. Creating a brand new Hello World C++ app in VS2015 the C++ project include directories inherit $(VC_IncludePath) and $(WindowsSDK_IncludePath). $(WindowsSDK_IncludePath) pulls in headers from C:\Program Files (x86)\Windows Kits\8.1 while $(VC_IncludePath) pulls in headers from C:\Program Files (x86)\Windows Kits\10.

So simple project upgrades fail with no error reported on the upgrade. Clean new console projects pull headers from 2 different Windows Kit installations simultaneously, and I now have entries for 8.1 and 10 under C:\Program Files (x86)\Microsoft SDKs and C:\Program Files (x86)\Windows Kits. Windows Kit 8.1 contains Win32 and WinRt headers, while Windows Kit 10 contains C/C++ headers.

Do I have a misconfigured and corrupted install or is this mess how it is supposed to be?

If this mess is how it is supposed to be, how is this intended to work? I've tried searching MSDN for info about Windows Kits but turned up nothing except stuff about the Windows Driver Kit, which used to be something completely different but I don't know whether it still is.

Is there any documentation out there that I've missed which explains the rationale behind this library configuration and how it's intended to be used?

1
Microsoft has a very difficult and demanding customer. Its name is Microsoft. The politics are boring and doesn't solve anybody's problem. You just need to fix Project > Properties > VC++ Directories > Include Directories. Restore its to $(VC_IncludePath);$(WindowsSDK_IncludePath) which evaluates to 5 directories. That probably breaks your project, use the C/C++ > General > Additional Include Directories setting instead.Hans Passant
I am sorry, but I am having difficulty understanding what parts of this is the problem you need to solve and what parts are just problems you are complaining about. If you are able to provide a simple sample of code then that would probably help.user34660
I'm trying to understand how Windows Kits relate to the old Windows SDKs and how one is expected to configure projects to work with different versions of them. It's a Visual Studio project configuration question, not a code problem. If you don't understand or aren't interested that's fine but please don't vote to close my question just because your not interested, because if a good answer does turn up that could still be very useful to other people.Neutrino
If you want this to be helpful to others, make sure your question is clear (see How to Ask). As currently written, it isn't exactly clear, what you are after. How to properly upgrade a solution from VS 2012 to 2015? How to verify whether your build system is properly set up? How the Windows SDK headers should be used? How to build using a particular SDK? Whether there is documentation available?IInspectable

1 Answers

6
votes

I've bumped into several different variations of this issue a few times now, with issues resolving both header files and library dependencies on projects upgraded from VS2012 to VS2015.

Hans' comment in reply to my question does indeed fix the issue for headers, but after encountering the same problem for library dependencies I have what might be a simpler solution that works for failed library dependency resolution too.

On opening a VS2012 project in VS2015 no automatic upgrade is performed. Opening the project properties and changing General -> Platform Toolset to Visual Studio 2015 (v140) will likely reproduce either a variant of the header resolution error described in my original question or a different library dependency resolution error.

The easiest way I've found to fix these is to open project properties and go to VC++ Directories -> Include Directories. In amongst any paths you may have added to your project yourself you will probably find $(VCInstallDir)\include;$(VCInstallDir\atlmfc\include;$(WindowsSDK_IncludePath)

Click the path to display the dropdown and click edit, this will display a dialog with three sections, from top to bottom, explicitly defined paths, evaluated paths and inherited paths. At the very bottom is a checkbox 'Inherit from parent or project defaults' which I've always found to be initially unchecked.

From the explicitly defined include paths delete the $(VCInstallDir)\include;$(VCInstallDir\atlmfc\include;$(WindowsSDK_IncludePath) entries described above and select the 'Inherit from parent or project defaults' setting. That should resolve any header file dependency issues.

If you also have library referencing issues do the same thing with the Library Directory entries, edit the settings, remove the explicit plaform entries and select 'Inherit from parent or project defaults'. (It might be a good idea to do this even if you aren't seeing any linker errors else you might end up using platform toolset compiler option for VS2015 while linking to libraries for VS2012).

I don't know why this is screwed up for me when I haven't come across anyone else having similar issues, I haven't had problems upgrading Visual Studio solutions before.

I also haven't discovered why some versions of Windows Kits now contain either Windows platform headers or C++ library headers, when previously SDK's always contained platform headers while C++ headers were always part or the Visual Studio installation. It seems like a change like this should have a dev blog about it somewhere or some other documentation. But as long as it works then I don't care too much.

I hope this helps somebody.