Select SDK under Windows

[amigo421]

please remind - is there (in extension settings) an ability to select from installed WinSDKs which one should be used for the build? is it possible to add this setting button to status bar in a line of the toolchain, build and debug type?

P.S. also, I've raised the request in cpp-tools repository regarding include paths for IntelliSense and navigation, based on the info of the current build. would be nice if the functionality from your extension, about -which toolchain and SDK are currently selected, can be exposed for the navigation, but this is just a question , you see - I 'm third party here :) , not a developer ...

[vector-of-bool]

That would go into the build environment detection code. Currently it just uses whatever environment batch scripts it can find for a few Visual Studio installs, but I haven't looked much into a corresponding environment selection for Windows SDKs

[amigo421]

I don't have sdk7 but suppose that should look similar to 8 (8.1) however sdk10 installations have another install rules: for one parent sdk10 install path, there can be a few subfolders for various minor version inside. as I see there is no info in a registry or any api functions to determine all of these (I found only a reference to latest SDK 10 with full version number).

this can be confirmed even by MS code - they do this: (enumerate all subfolders named as version number under SDKs 10 "include" folder)

for /f %%i IN ('dir "%WindowsSdkDir%include\" /b /ad-h /on') DO (
...)

So if we need to enumerate installed SDKs we have to perform the steps :

• read the registry : this key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots contains a root paths in a keys (KitsRoot*):

  KitsRoot10
  KitsRoot81

for sure, MS uses another way and probably that one is more reliable: they try read SDK roots from the registry paths combined from (one by one, until success)):

    - HKLM\SOFTWARE\Wow6432Node
    - HKCU\SOFTWARE\Wow6432Node
    - HKLM\SOFTWARE
    - HKCU\SOFTWARE

and this subpath and a key:

     \Microsoft\Microsoft SDKs\Windows\v8.1" /v "InstallationFolder"'

or

      \Microsoft\Microsoft SDKs\Windows\v10.0" /v "InstallationFolder"

• if 8.1 or earlier were detected they can be added into the list of available ones as is . but for 10 additional step is required - do exactly the same like MS does in batch code above: extract full version numbers from "include" subfolder names.

[vector-of-bool]

There's been talk of reworking the "build environment" stuff into something more fleshed out and akin to QtCreator's Kits. I could see this going in that direction.

[Djoulihen]

As mentioned in #1332, this could probably be implemented by adding a parameter for visual studio kits. The kits currently have "visualStudioArchitecture" which is passed to vcvarsall.bat (after some naming conversion) when retrieving the environment variables necessary for the msvc compiler to work.

Adding a "visualStudioWinSDKVersion" parameter could allow the user instruct cmake-tools to also pass that parameter to vcvarsall.bat to correctly select the Windows SDK instead of taking the default (latest ?) one.

I've also looked at using environment variables to control the selection of the SDK but did not come up with a satisfactory solution.

[lygstate]

T

Adding a "visualStudioWinSDKVersion" parameter could allow the user instruct cmake-tools to also pass that parameter to vcvarsall.bat to correctly select the Windows SDK instead of taking the default (latest ?) one.

How to using visualStudioWinSDKVersion parameter?

[chrisjaquet]

This would be a very handy feature. For various reasons (e.g supporting older software) I need to be able to specify an older Win10 SDK than is selected by default.

Usually I set up my environment on the command line using the vcvarsall.bat files and pass in the required SDK version (e.g. 10.0.19041.0) and then run tools like CMake from that command window, passing in options such as -DCMAKE_SYSTEM_VERSION=10.0.19041.0 to indicate the SDK I want to use. CMake seems to respect the options when run from the command line, but when opening VSCode and generating the project files the toolkit uses the newer SDK version, bypassing the already-configured environment.

For now the only way I have found to avoid this is to uninstall newer SDKs than the one I want to use, and then reinstall them when I am no longer working on the older project.