2017-01-11 4 views
1

У меня есть решение clickonce, которое работает на нескольких машинах разработчика с установленным VS 2015. Тем не менее, это не работает на нашем buildserver, он поставляется с этой ошибкой signFile. Я установилошибка MSB4018: задача «SignFile» неожиданно завершилась неудачно на сервере сборки

  • Строительные инструменты 2015 обновления 3
  • .Net 4.6.2 SDK
  • Разработка программного обеспечения для Windows Kit

Но Apparantly путь к signtool.exe не правильно настроен , Если я отключу подписание манифеста, он будет продолжен, но придет ошибка с setup.bin.

У кого-нибудь есть хорошая подсказка, как решить проблему SignFile?

[_DeploymentComputeClickOnceManifestInfo] Using "SignFile" task from assembly "Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". 
[_DeploymentComputeClickOnceManifestInfo] SignFile 
[SignFile] C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(3616, 5): error MSB4018: The "SignFile" task failed unexpectedly. 
System.ArgumentNullException: Value cannot be null. 
Parameter name: path1 
    at System.IO.Path.Combine(String path1, String path2, String path3) 
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities.GetPathToTool(ResourceManager resources) 
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities.SignPEFile(X509Certificate2 cert, Uri timestampUrl, String path, ResourceManager resources, Boolean useSha256) 
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities.SignFileInternal(X509Certificate2 cert, Uri timestampUrl, String path, Boolean targetFrameworkSupportsSha256, ResourceManager resources) 
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities.SignFile(X509Certificate2 cert, Uri timestampUrl, String path) 
    at Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities.SignFile(String certThumbprint, Uri timestampUrl, String path, String targetFrameworkVersion) 
    at Microsoft.Build.Tasks.SignFile.Execute() 
    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() 
    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() 

ответ

1

Ошибка бросают на line 195 из Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilities, что в следующем методе:

internal static string GetPathToTool() 
    { 
     string pathToDotNetFrameworkSdkFile = ToolLocationHelper.GetPathToDotNetFrameworkSdkFile(ToolName(), TargetDotNetFrameworkVersion.Version35); 
     if (pathToDotNetFrameworkSdkFile == null) 
     { 
      pathToDotNetFrameworkSdkFile = Path.Combine(Environment.CurrentDirectory, ToolName()); 
     } 
     if (!File.Exists(pathToDotNetFrameworkSdkFile)) 
     { 
      pathToDotNetFrameworkSdkFile = null; 
     } 
     return pathToDotNetFrameworkSdkFile; 
    } 

Непосредственной причиной было то, что Environment.CurrentDirectory вернулся null, но более заметным было то, что ToolLocationHelper.GetPathToDotNetFrameworkSdkFile(ToolName(), TargetDotNetFrameworkVersion.Version35) также вернулся null.

Приведенный выше код представляет собой только снимок конкретной версии класса, но жёстко значение перечисления TargetDotNetFrameworkVersion.Version35 говорит мне, что проблема заключается в том, что Строительные инструменты 2015 обновления 3 зависит от версии .NET SDK другой, чем 4.6.2.

UPDATE:

Чтобы определить конкретную версию SDK, я снесла исходный код выхода Update 3 в https://github.com/Microsoft/msbuild/releases.

internal static string GetPathToTool(System.Resources.ResourceManager resources) 
    { 
#pragma warning disable 618 // Disabling warning on using internal ToolLocationHelper API. At some point we should migrate this. 
     string toolPath = ToolLocationHelper.GetPathToWindowsSdkFile(ToolName, TargetDotNetFrameworkVersion.VersionLatest, VisualStudioVersion.VersionLatest); 
     if (toolPath == null) 
      toolPath = ToolLocationHelper.GetPathToWindowsSdkFile(ToolName, TargetDotNetFrameworkVersion.Version45, VisualStudioVersion.Version110); 
     if (toolPath == null) 
      toolPath = Path.Combine(ToolLocationHelper.GetPathToDotNetFrameworkSdk(TargetDotNetFrameworkVersion.Version40, VisualStudioVersion.Version100), "bin", ToolName); 
     if (toolPath == null) 
      toolPath = Path.Combine(Directory.GetCurrentDirectory(), ToolName); 
     if (!File.Exists(toolPath)) 
      throw new ApplicationException(String.Format(CultureInfo.CurrentCulture, resources.GetString("SecurityUtil.SigntoolNotFound"), toolPath)); 
     return toolPath; 
#pragma warning restore 618 
    } 

Копаем дальше в решении, я решил, что последняя версия утилиты сборки (один установлен) не включает в себя change к Shared\FrameworkLocationHelper.cs, что добавлена ​​поддержка Framework 4.6.2. Поэтому, чтобы ответить на ваш последующий вопрос, установка 4.6.1 SDK должна сделать трюк.

ОБНОВЛЕНИЕ 2:

ОП определили альтернативное решение: явно устанавливая значение TargetFrameworkSDKToolsDirectory собственности, например, добавив /p:TargetFrameworkSDKToolsDirectory=PATH TO SIGNTOOL.EXE(?) в качестве аргумента при вызове msbuild.exe из командной строки.

+1

Я не знаю, как вы это поняли, но спасибо. Вы случайно знаете, на какой SDK это зависит, поэтому мне не нужно устанавливать все? Прямо сейчас я обошел это, установив свойство/свойство: TargetFrameworkSDKToolsDirectory при вызове msbuild. –

+0

Отвечено обновлено этой информацией (я надеюсь, что я прав!). Что касается того, как я это понял, я начал с обращения к файлу и номеру строки, указанному в верхней части вашего журнала ошибок. Когда я увидел, что задача 'SignFile' не взяла параметр для пути к инструменту/исполняемому файлу, я знал, что мне нужно будет увидеть исходный код задачи' SignFile'. К счастью, MSBuild теперь с открытым исходным кодом! – weir

+0

@dennis_ler - я добавил к этому ответу исправление 'TargetFrameworkSDKToolsDirectory'. – weir

Смежные вопросы