使用dotnet build执行SignFile时出现Build-Error问题求助

这个问题的核心原因在于Visual Studio使用的是桌面版MSBuild，而dotnet build调用的是.NET Core SDK自带的跨平台MSBuild，两者包含的任务集不同——SignFile任务属于桌面MSBuild的组件，跨平台MSBuild默认没有包含它。下面给你两个可行的解决方案，适配你的TFS构建场景：

方案1：使用dotnet sign CLI命令替代MSBuild任务 #

这是最推荐的方案，完全适配dotnet CLI的构建流程，不依赖Visual Studio的MSBuild组件，适合CI环境：

1. 先从你的csproj文件中移除之前添加的PostBuild目标节点。
2. 在TFS的构建脚本中，调整为在dotnet build完成后，单独执行dotnet sign命令：

   dotnet build YourProject.csproj --configuration Release
   dotnet sign $(Build.ArtifactStagingDirectory)/path/to/your.dll --certificate-thumbprint {some-sha-code}
   

   如果需要自动定位输出文件，也可以用MSBuild变量配合，比如针对类库项目：

   dotnet sign $(TargetPath) --certificate-thumbprint {some-sha-code}
   

   这个命令会自动处理签名，和SignFile任务的效果一致，且能在dotnet CLI环境下稳定运行。

方案2：手动添加UsingTask声明指定任务程序集 #

如果你坚持要在MSBuild脚本中保留SignFile任务，需要在csproj里添加UsingTask节点，明确告诉dotnet build的MSBuild去哪里找到SignFile任务的程序集：

在你的csproj文件中，添加以下代码（放在<Project>节点内即可）：

<UsingTask TaskName="Microsoft.Build.Tasks.SignFile" 
           AssemblyFile="$(VSINSTALLDIR)MSBuild\Current\Bin\Microsoft.Build.Tasks.Core.dll" />

• $(VSINSTALLDIR)是Visual Studio安装目录的环境变量，在安装了VS2019的构建代理上会自动识别。
• 如果你的构建代理没有安装完整的Visual Studio，也可以通过vswhere工具动态获取路径，或者直接指定绝对路径（注意路径要适配代理的系统架构）。

不过这个方案的缺点是依赖Visual Studio的安装，不如dotnet sign灵活，适合必须在MSBuild流程内完成签名的场景。

补充说明：你的TFS环境用dotnet build和dotnet pack的流程是合理的，VSBUILD确实会在pack环节出现兼容性问题，所以优先选择方案1能避免后续的构建稳定性问题。

内容的提问来源于stack exchange，提问作者Martini Bianco