Frage

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.)

War es hilfreich?

Lösung

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.

Andere Tipps

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: Visual Studio 2015 Setup where you can add ClickOnce

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 enter image description here

and type in where signtool.exe

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>
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

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>

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.

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.

Screenshot of signtool being resolved

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.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top