Path to SignTool.exe or “Windows Kits” directory w

2019-03-08 10:19发布

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

4条回答
我只想做你的唯一
2楼-- · 2019-03-08 10:25

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>
查看更多
Deceive 欺骗
3楼-- · 2019-03-08 10:30

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

查看更多
Melony?
4楼-- · 2019-03-08 10:31
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
查看更多
Luminary・发光体
5楼-- · 2019-03-08 10:45

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.

查看更多
登录 后发表回答