Путь к каталогу SignTool.exe или Windows Kits при использовании Visual Studio 2012

Я только что столкнулся с той же проблемой. Запуск сборки из командной строки Visual Studio 2012 работал, но в среде IDE происходил сбой. Поиск подробного или диагностического журнала привел меня к Каково расположение по умолчанию для Журналы MSBuild?, которые сказали мне, что Visual Studio не может предоставить диагностическую информацию, которая мне действительно нужна.

Вот что я наконец сделал, чтобы исправить это.

Откройте обычную командную строку (не командную строку Visual Studio) и запустите из нее msbuild, указав полный путь к MSBuild (%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe). Это, наконец, дало мне то же сообщение об ошибке (код ошибки 9009), которое я получал в Visual Studio 2012.

Затем запустите ту же сборку, используя «диагностическую» регистрацию (которая показывает все значения свойств и элементов), добавив переключатель /v:diag.

Из этого вывода я узнал, что у него есть некоторые новые свойства, которые я могу использовать для получения местоположения signtool.exe (отрывок ниже):

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\

Итак, мое решение этой проблемы состояло в том, чтобы добавить в мой файл *.targets следующее:

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

Надеюсь, это поможет и вам. Я включил преамбулу того, как я пришел к этому моменту, потому что есть другие доступные свойства, которые могут лучше подходить для ваших целей.

Хорошо, поскольку это был первый поиск в Google по запросу «SignTool.exe не найден на сервере сборки», я добавлю дополнительную информацию для VisualStudio 2015 и Windows 10 Enterprise 64bit.

Мне пришлось добавить средства публикации ClickOnce в программу установки VisualStudio:

После этого вы найдете signtool.exe в

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

Если установлена ​​Visual Studio 2017, она находится в

• 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

А с Visual Studio 2017 15.7.4 путь снова изменился в соответствии с выбранным комплектом Windows 10, который вы устанавливаете.

Вы получите общий путь, запустив Командную строку разработчика для Visual Studio 2017

и введите where signtool.exe

Ниже приведен более общий подход, который можно использовать для поиска и установки переменной SignToolPath на основе конкретной конфигурации машины сборки; прочитав реестр:

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

Это предполагает, что $(Platform) разрешается в одно из arm, x86 или x64. В противном случае замените макрос $(Platform) соответствующим каталогом.

РЕДАКТИРОВАТЬ (2017.07.05):
Вот обновленный <PropertyGroup>, который относится к новому комплекту Windows 10 и приводит ($Platform)=='AnyCPU' к 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"

Вывод:

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

Поскольку для меня сегодня (20.07.2020) все предыдущие предложения не увенчались успехом, хотя большинство из них работали в прошлом, я решил опубликовать более комплексный подход, который также касается более поздних местоположений Windows 10 SDK, при этом все еще используя старые в качестве запасных вариантов.

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

Я предполагаю, что signtool используется для подписи исполняемых файлов или DLL. В Visual Studio 2019 есть командная строка разработчика, которая предлагает как Developer Cmd, так и Developer Powershell. Оба эти варианта могут автоматически разрешать средство подписи, не беспокоясь о текущем Windows SDK.

Если мы хотим использовать Developer Powershell из собственного powershell, нам просто нужно импортировать модуль для Developer Powershell. Чтобы импортировать модуль, нам нужно запустить следующую строку в родном powershell:

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

где 5ee267ff варьируется для каждой машины. Вы можете узнать это в свойствах ярлыка Developer Powershell.

После того, как модуль импортирован, мы можем разрешить signtool даже из родной оболочки powershell. В конце мы можем добавить сценарий в событие после сборки проекта, чтобы этот сценарий импортировал PowerShell разработчика, а затем мы могли просто использовать инструмент подписи для подписи.

Этот подход, который я использую, просто опирается на стандартные события сборки:

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

Он справится с новыми путями по мере установки новых Windows SDK и выберет самый последний.