2017-01-11 97 views
1

我有一個clickonce解決方案,適用於安裝了VS 2015的多個開發人員計算機。但是,它不適用於我們的buildserver,它帶有這個signFile錯誤。我已經安裝了錯誤MSB4018:構建服務器上的「SignFile」任務意外失敗

  • 生成工具2015年更新3
  • 淨4.6.2 SDK
  • Windows軟件開發工具包

但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

被拋出對Microsoft.Build.Tasks.Deployment.ManifestUtilities.SecurityUtilitiesline 195的錯誤,這是在下面的方法:

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版本,我在https://github.com/Microsoft/msbuild/releases從更新3版本拉低了源代碼。

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 
    } 

進一步翻閱的解決方案,我決定構建工具的最新版本(安裝了一個),不包括changeShared\FrameworkLocationHelper.cs是增加了對框架4.6.2支持。因此,要回答您的後續問題,安裝4.6.1 SDK的應該執行技巧

更新2:

的OP識別的替代解決方案:顯式設置TargetFrameworkSDKToolsDirectory屬性的值,例如在從命令行調用msbuild.exe時,通過添加/p:TargetFrameworkSDKToolsDirectory=PATH TO SIGNTOOL.EXE(?)作爲參數。

+1

我不知道你是怎麼想出來的,但是謝謝。你有沒有機會知道它依賴於哪個SDK,所以我不需要全部安裝?現在我通過在調用msbuild時設置屬性/屬性:TargetFrameworkSDKToolsDirectory來規避此問題。 –

+0

回覆更新了這個信息(我希望我是對的!)。至於我如何解決這個問題,我首先找到錯誤日誌頂部附近引用的文件和行號。當我看到'SignFile'任務沒有爲工具/可執行文件的路徑添加參數時,我知道我需要查看'SignFile'任務的源代碼。幸運的是,MSBuild現在是開源的! – weir

+0

@dennis_ler - 我已將您的'TargetFrameworkSDKToolsDirectory'修復程序添加到此答案。 – weir

相關問題