Path to SignTool.exe or "Windows Kits" directory when using Visual Studio 2012

Question

How do you get the path to SignTool.exe when using Visual Studio 2012?

In Visual Studio 2010, you could use

<Exec Command="&quot;$(FrameworkSDKDir)bin\signtool.exe&quot; sign /p ... />

Where $(FrameworkSDKDir) is

"c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\"

But in Visual Studio 2012, $(FrameworkSDKDir) is

 "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\"

and SignTool is in

 "c:\Program Files (x86)\Windows Kits\8.0\bin\x64\"

Is there a way of getting the path to this directory other than hard coding (I've tried FrameworkSDKDir and WindowsSDKDir, but both point to the v8.0A directory).

(I am aware of the SignFile MSBuild task, but I can't use that as it doesn't accept certificate passwords.)

$(FrameworkSdkDir) points to Windows Kits on my machine. Don't mix up with $(FrameworkSDKRoot), the capitalization is wrong in your question. — Hans Passant, Dec 29 '12 at 14:09
MSBuild properties are case insensitive from my testing. FrameworkSDKRoot / FrameworkSdkDir point to the same place in my project - C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\ — Ryan, Dec 29 '12 at 14:51
@Ryan they may point to the same place but that's not a matter of case sensitivity. — Edward Thomson, Dec 29 '12 at 17:25
@EdwardThomson - Sure about that? Take any property you care for in MSBUILD and output via message with CraZY cAse - it will work. Try it! — Ryan, Dec 29 '12 at 18:46
@Ryan - I'm saying that `FrameworkSdkDir` and `FrameworkSdkRoot` do not differ in case, but in content. — Edward Thomson, Dec 29 '12 at 18:57

score 44 · Accepted Answer · edited May 23 '17 at 12:34

I just ran into the same issue. Running the build from a Visual Studio 2012 Command Prompt worked, but it was failing in the IDE. Looking for a detailed or diagnostic log led me to What is the default location for MSBuild logs?, which told me that Visual Studio can't give the diagnostic information I really needed.

Here's what I finally did to fix it.

Open a normal Command Prompt (not the Visual Studio Command Prompt), and run msbuild from that by fully-qualifying the path to MSBuild (%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe). This finally gave me the same error message (error code 9009) that I had been receiving in Visual Studio 2012.

Then, run the same build using "diagnostic" logging (which shows all property and item values) by appending the /v:diag switch.

From this output, I learned that it does have some new properties that I could use to get the location of signtool.exe (excerpt below):

windir = C:\Windows
windows_tracing_flags = 3
windows_tracing_logfile = C:\BVTBin\Tests\installpackage\csilogfile.log
WindowsSDK80Path = C:\Program Files (x86)\Windows Kits\8.0\
WIX = C:\Program Files (x86)\WiX Toolset v3.7\

So, my solution to this problem was to add the following to my *.targets file:

<SignToolPath Condition=" Exists('$(WindowsSDK80Path)bin\x86\signtool.exe') and '$(SignToolPath)'=='' and '$(PROCESSOR_ARCHITECTURE)'=='x86' ">$(WindowsSDK80Path)bin\x86\signtool.exe</SignToolPath>
<SignToolPath Condition=" Exists('$(WindowsSDK80Path)bin\x64\signtool.exe') and '$(SignToolPath)'=='' and '$(PROCESSOR_ARCHITECTURE)'=='AMD64' ">$(WindowsSDK80Path)bin\x64\signtool.exe</SignToolPath>

Hope this helps you, too. I included the preamble of how I got to this point because there are other properties available that may be better suited for your purposes.

This is from two years ago but can you explain how you added it to your targets? My workaround was to add to the post build event: IF EXIST "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe" "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe" sign /a /d "QA" $(ProjectDir)obj\$(PlatformName)\$(ConfigurationName)\QA.exe — Jaydel Gluckie, Oct 13 '15 at 17:56

gReX · Answer 2 · 2018-06-24T19:05:52.397

Ok, because this was the first hit on google for "SignTool.exe not found on buildserver", I will add additonal Info for VisualStudio 2015 and Windows 10 Enterprise 64bit.

I had to add the ClickOnce Publishing Tools in VisualStudio Setup:

After this you find signtool.exe in

c:\Program Files (x86)\Windows Kits\8.1\bin\x64\
c:\Program Files (x86)\Windows Kits\8.1\bin\x86\
c:\Program Files (x86)\Windows Kits\8.1\bin\arm\

With Visual Studio 2017 installed it is found in

C:\Program Files (x86)\Windows Kits\10\bin\arm\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\arm64\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe

And with Visual Studio 2017 15.7.4 the Path changed again according do the selected Windows 10 Kit you install.

You will get the path generic by starting the Developer Command Prompt for Visual Studio 2017

and type in where signtool.exe

And if you've already installed VS2015, you can go to the Control Panel -> Add/Remove Programs -> right click on MS Visual Studio and select Change to re-run this setup wizard and add the option above — sfm, Jul 15 '16 at 19:40

ergohack · Answer 3 · 2017-07-05T18:48:09.693

12

The following is a more generic approach that can be used to find and set the SignToolPath variable based upon the build machine's specific configuration; by reading the registry:

<PropertyGroup>
    <WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
    <WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
    <SignToolPath Condition="'$(SignToolPath)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolPath>
</PropertyGroup>

This assumes that $(Platform) resolves to one of arm, x86, or x64. Replace the $(Platform) macro with the appropriate directory otherwise.

EDIT (2017.07.05):
Here is an updated <PropertyGroup> that defers to the new Windows 10 Kit and coerces the ($Platform)=='AnyCPU' to x86:

<PropertyGroup>
  <WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
  <WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
  <WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
  <SignToolPath Condition=" '$(SignToolPath)' == '' And '$(Platform)' == 'AnyCPU' ">$(WindowsKitsRoot)bin\x86\</SignToolPath>
  <SignToolPath Condition="'$(SignToolPath)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolPath>
</PropertyGroup>

edited Jul 05 '17 at 18:48

answered Dec 08 '15 at 19:34

ergohack

1,268
15
27

When compiling for 'AnyCPU' you still have to specify one of `arm`, `x86`, or `x64` for the complete path to the signtool executable. If you only ever compile with `AnyCPU` then replace the `$(Platform)` macro with the appropriate explicit path fragment. – ergohack Jan 24 '16 at 04:56
1

If you compile with `AnyCPU` and specific platforms then you will need the following two conditional statements: – ergohack Jan 24 '16 at 04:58
3

`$(WindowsKitsRoot)bin\x64\` `$(WindowsKitsRoot)bin\$(Platform)\` – ergohack Jan 24 '16 at 05:00
@ErgoHack does this just go in the csproj file? If so towards the bottom or top? I'm still having issues with it finding the path for signtool even when the build machine's VS command prompt can find it – Randy Walker Apr 27 '17 at 22:31
1

@Randy Walker, The goes near the top so that the properties are defined ahead of where they are needed. The `Condition="'$(SignToolPath)'==''"` keeps the property from being set if the define is already set. So an environment variable in the OS will keep this from being overridden during the build. – ergohack Apr 29 '17 at 02:21
1

@RandyWalker, Also, check the registry key manually on the computer having problems. Instead of the ones above, my Windows 10 computer uses the following registry path: `$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))`. – ergohack Apr 29 '17 at 02:42
1

@RandyWalker, Also, also, check the other `.targets` files in your build environment for the call to `GetRegistryValueFromView()` in case the parameters (e.g. the `RegistryView.Registry32`) are the same as above. – ergohack Apr 29 '17 at 02:47
@ErgoHack ok for some reason it's magically stopped giving me the error for signtool. However the log file doesn't say anything about it actually signing the manifest and I keep getting the same error "The deployment identity does not match the subscription." Any thoughts on how one might fix the issue? Happy to post a new issue so that you can get credit. Heck I might even hire you if you think you can fix the problem. My last devs were building off of TFS and I moved the code to GitHub. – Randy Walker May 07 '17 at 05:38
1

@Randy, it sounds like it isn't being run from the build scripts. You can use the element (see http://stackoverflow.com/questions/4771913/how-to-output-a-variable-value-to-the-log-from-msbuild ) to get the insight of what the variables are set to and what lines are being run. – ergohack May 08 '17 at 22:48

hdev · Answer 4 · 2023-06-24T18:23:48.073

Powershell Command:

Resolve-Path  "C:\Program Files*\Windows Kits\*\bin\*\signtool.exe"

Output:

Path
----
C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\arm\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe

score 5 · Answer 5 · answered Jul 20 '20 at 22:03

Since for me, today (20/07/2020), all previous suggestions failed, although most of them worked in the past, I have decided to publish a more comprehensive approach, which also addresses later Windows 10 SDKs locations, while still using older ones as fallbacks.

<PropertyGroup Label="UserDefinedVariables">

    <!-- Get Windows SDK root folder-->

    <WindowsKitsRoot>$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot10', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
    <WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot81', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>
    <WindowsKitsRoot Condition="'$(WindowsKitsRoot)' == ''">$([MSBuild]::GetRegistryValueFromView('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots', 'KitsRoot', null, RegistryView.Registry32, RegistryView.Default))</WindowsKitsRoot>

    <!-- Evaluates the most recent Windows SDK folder containing SignTool.exe -->

    <!-- add new versions here, duplicating following line -->
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.18362.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.18362.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.17763.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.17763.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.17134.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.17134.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.16299.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.16299.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.15063.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.15063.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And exists('$(WindowsKitsRoot)bin\10.0.14393.0\x64\Signtool.exe')">$(WindowsKitsRoot)bin\10.0.14393.0\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == '' And '$(Platform)' == 'AnyCPU' ">$(WindowsKitsRoot)bin\x64\</SignToolFolder>
    <SignToolFolder Condition="'$(SignToolFolder)' == ''">$(WindowsKitsRoot)bin\$(Platform)\</SignToolFolder>

    <!-- Now we should be able to calculate SignTool.exe fullpath -->

    <SignToolExe Condition=" '$(SignToolFolder)' != '' ">$(SignToolFolder)SignTool.exe</SignToolExe>

</PropertyGroup>


<!-- Finally, I would suggest you add the following lines to your project file because they will be quite usefull when things go wrong (and they will) -->

<!-- Send indivual compile bessages to MSBuild output so you check the value of each variable -->
<Target Name="ShowUserDefinedVariables" BeforeTargets="BeforeBuild">
    <Message Importance="High" Text="WindowsKitsRoot = $(WindowsKitsRoot)" />
    <Message Importance="High" Text="SignToolFolder = $(SignToolFolder)" />
    <Message Importance="High" Text="SignToolExe = $(SignToolExe)" />
</Target>

score 3 · Answer 6 · answered Jan 15 '21 at 12:07

3

This approach I'm using just relies on the standard build events:

powershell -Command "(Resolve-Path \"C:\Program Files (x86)\\Windows Kits\\10\\bin\\*\\x64\" | Select-Object -Last 1).Path" > stpath
set /p STPATH=<stpath
del stpath

"%STPATH%\signtool.exe" sign ..........

It will cope with new paths as new Windows SDKs get installed and pick the latest one.

answered Jan 15 '21 at 12:07

PhonicUK

13,486
4
43
62

1

Thanks for the great solution. Here's a slight improvement of the first line: `powershell -Command "(Resolve-Path \"%ProgramFiles(x86)%\Windows Kits\10\bin\*\x64\" | Select-Object -Last 1).Path" > stpath` – Bernhard Zechmeister Oct 20 '22 at 14:03
This doesn't handle the case if no Windows 10 kits are installed on the machine – Tur1ng Mar 07 '23 at 00:39

Navjot Singh · Answer 7 · 2020-08-27T14:49:27.470

I assume that signtool is being used to sign the executables or dlls. With Visual Studio 2019, there is a Developer command line which offers both Developer Cmd and Developer Powershell. Both of these options can resolve the signtool automatically without worrying about the current Windows SDK.

If we want to use the Developer Powershell from the native powershell then we just need to import the module for Developer Powershell. To import the module we need to run the following line in native powershell:

&{Import-Module "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools\Microsoft.VisualStudio.DevShell.dll"; Enter-VsDevShell 5ee267ff}

where 5ee267ff varies for each machine. You can find it out in the Properties of Developer Powershell shortcut.

Once the module is imported we can resolve signtool even from native powershell. In the end we can add a script in the post build event of a project such that this script imports the Developer powershell and then we can simply use signtool for signature.

Path to SignTool.exe or "Windows Kits" directory when using Visual Studio 2012

7 Answers7

Linked