26

TL;DR

Is there a Windows registry key (or other easily-programmable way) to find & detect the Windows SDK, which works for SDK V10.0?

I am doing something similar to this, i.e. making use of some of the tooling accompanying the Windows 10 SDK.

I am looking for a programatic way to detect and locate the Windows SDK. This technique must work for (at least) version 10.0 (current as of this question). Preferably, I would like a technique that works for all versions (and world peace would be nice too).

Previous versions (at least up to V8.1A - as was included with Visual Studio 2013) were detectable via the windows registry. (Although V<7.0 may not have been).

For 64-bit installations: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows (note the bolded difference from 32-bit).

While for 32-bit installs: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows, and HKEY_CURRENT_USER\SOFTWARE\Microsoft\Microsoft SDKs\Windows

(More on that at the MSDN Windows SDK blog).

However, V10.0 (or V10.0A as is included with Visual Studio 2015) does not make a registry key as did previous versions!

There are techniques using compiler macros to detect the SDK version. However, these are not practical simply for SDK tool use (xsd.exe, etc), as they would require an entire compilation step - AND this would not necessarily yield a path to the SDK's tool directory!

Ideally, this should be achievable using PowerShell or a batch script or some other simple means that can be included in a build script or other automated environment (they are programming tools after all).

Note:

Yes there are ways to do this by interrogating the file-system, (i.e. programmatically listing subdirectories of %ProgramFiles(x86)%\Microsoft SDKs\Windows\, parsing out the 'V' and 'A'-s and selecting the max() of the numbers listed (10.0, etc)...

HOWEVER, these approaches have a number of drawbacks:

  1. Quite clunky (filesystem access, string parsing, etc)
  2. Error prone, an empty folder leftover from an incorrectly uninstalled SDK could brake said clunky directory parsing.
  3. Subject to path differences, by platform (i.e. %ProgramFiles(x86)% on x64, but %ProgramFiles% on 32-bit), and by SDK version; SDK<7 locates tooling inside a Bin directory, while SDK>7 uses bin\NETFX X.X tools (note the lowercase 'b', just for added inconsistency).
  4. Also subject to user installation choices ("clever" sys admin installed the SDK in C:\Stuff\WinSDK\V10.0\, for example).

Hence it would be MUCH better to achieve this programmatically, such as via the registry (as is possible for previous Windows SDK versions)

This question is not a duplicate of this one, as this question is both asking about a different SDK version, and is also asking about a programmatic (i.e. registry, etc) way to find the SDK path.

Nor is it a duplicate of this, as that question was dealing specifically with cmake and involved a build-number mismatch.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Tersosauros
  • 883
  • 1
  • 12
  • 22

3 Answers3

12

As of now, the best way I've found is to look at how Visual Studio's dev command does it. Currently (2019) this is found in winsdk.bat under .\Common7\Tools\vsdevcmd\core\ in your Visual Studio directory. This should help if things are changed again in the future. Even if winsdk.bat is renamed or reorganised, hopefully similar scripts will still be included.

On my system the relevant section currently looks like this:

:GetWin10SdkDir

call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
if errorlevel 1 exit /B 1
exit /B 0


:GetWin10SdkDirHelper

@REM `Get Windows 10 SDK installed folder`
for /F "tokens=1,2*" %%i in ('reg query "%1\Microsoft\Microsoft SDKs\Windows\v10.0" /v "InstallationFolder"') DO (
    if "%%i"=="InstallationFolder" (
        SET WindowsSdkDir=%%~k
    )
)

@REM `get windows 10 sdk version number`
setlocal enableDelayedExpansion

@REM `Due to the SDK installer changes beginning with the 10.0.15063.0 (RS2 SDK), there is a chance that the
@REM Windows SDK installed may not have the full set of bits required for all application scenarios.
@REM We check for the existence of a file we know to be included in the "App" and "Desktop" portions
@REM of the Windows SDK, depending on the Developer Command Prompt's -app_platform configuration.
@REM If "windows.h" (UWP) or "winsdkver.h" (Desktop) are not found, the directory will be skipped as
@REM a candidate default value for [WindowsSdkDir].`
set __check_file=winsdkver.h
if /I "%VSCMD_ARG_APP_PLAT%"=="UWP" set __check_file=Windows.h

if not "%WindowsSdkDir%"=="" for /f %%i IN ('dir "%WindowsSdkDir%include\" /b /ad-h /on') DO (
    @REM `Skip if Windows.h|winsdkver (based upon -app_platform configuration) is not found in %%i\um.`
    if EXIST "%WindowsSdkDir%include\%%i\um\%__check_file%" (
        set result=%%i
        if "!result:~0,3!"=="10." (
            set SDK=!result!
            if "!result!"=="%VSCMD_ARG_WINSDK%" set findSDK=1
        )
    )
)
ChrisD
  • 3,378
  • 3
  • 35
  • 40
10

I don't have an authoritative source for it, but it traces back from the uninstaller of the Windows 10 SDK, and it checked out on a couple of machines I looked at:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Roots
KitsRoot10="C:\Program Files (x86)\Windows Kits\10\"

The exact version is a bit trickier to guess, since for example 10.0.10150.0, 10.0.10240.0 and 10.0.10586.0 are all subdirectories under C:\Program Files (x86)\Windows Kits\10\Include.

dxiv
  • 16,984
  • 2
  • 27
  • 49
  • +1, Although I think the "Windows Kits" here refers more-so to `Windows Assessment and Deployment Kits` (ADK), not the SDK. Although `HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Products` did have "Windows Software Development Kit x86" as a key value. Might require a little more investigating. – Tersosauros Feb 03 '16 at 14:50
  • @Tersosauros That's a good point. Though I have more `KitsRoot##` entries under that key than I have ADK versions installed. Guess the ultimate proof would be to install the SDK on a clean VM but I don't have one handy right now. – dxiv Feb 03 '16 at 15:52
  • @Tersosauros No, it's the SDK. I have no ADK installed on my current machine, but still have this key pointing to the SDK installation. There is also a key with "KitsRoot81", which points to the Windows 8.1 SDK. – Leandros May 26 '17 at 11:31
6

My Windows Kits key did not contain any information about the v10 Windows SDK. However, I found information about it at the following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK

Inside, there are subkeys for installed .NET versions. I had 4.6, 4.6.1, and 4.6.2.

Each of those keys contains a value InstallationFolder which points to the folder where the SDK is installed to (this would be C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\), and a value KitsInstallationFolder which contains the path to the kit containing the libraries (C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\).

More interestingly (for me at least), each of those keys also contains three more keys: WinSDK-NetFx40Tools, WinSDK-NetFx40Tools-x64, and WinSDK-NetFx40Tools-x86. And each of those keys has a value InstallationFolder that contains the absolute path to the tools folder of the specified SDK version.

So for my use case, I’m now doing the following in PowerShell to get the folder to the latest SDK Tools:

$WindowsSdkToolsPath = gci 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\NETFXSDK' |
    select -Last 1 |
    gci | ? { $_.PSChildName -eq 'WinSDK-NetFx40Tools' } |
    Get-ItemPropertyValue -Name InstallationFolder
poke
  • 369,085
  • 72
  • 557
  • 602