在“托管的VS2017”和自托管的构建代理（Windows Server 2012 R2）上，运行dotnet publish并指定了发布配置文件会失败，
C：\ Program 文件\ dotnet \ sdk \ 2.1.502 \ Sdks \ Microsoft.NET.Sdk \ targets \ Microsoft.PackageDependencyResolution.targets（198,5）： 错误NETSDK1047：资产文件 'C：\ agent_work \ 11 \ s \\ obj \ project.assets.json'没有 “ .NETCoreApp，版本= v2.1 / win-x64”的目标。确保还原具有 运行，并且您已在TargetFrameworks中包含“ netcoreapp2.1” 为您的项目。您可能还需要在您的计算机中包含“ win-x64” 项目的RuntimeIdentifiers。
在本地dev服务器（Win10，VS2017，许多不同的.net sdk版本）上，当我用完全相同的命令行发布dotnet时，一切正常。
我已经尝试了一切，从更新VS2017，安装我们要定位的.net核心SDK和运行时的确切版本，更新生成代理，Windows更新...似乎没有任何帮助。我不明白为什么它有不同的行为。
发布概要文件是FileSystem概要文件，并指定了以下两个元素：
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
命令行如下："C:\Program Files\dotnet\dotnet.exe" publish "C:\agent\_work\11\s\Source\TheProject.csproj" --no-build -c Release -f netcoreapp2.1 /p:PublishProfile="Publish Release To Filesystem.pubxml" -o C:\agent\_work\11\a\Website -v d
有人知道如何使它起作用吗？
答案 0 :(得分：0)
这完全是有关运行时标识符的。之所以引起混乱，是因为我认为从dotnet-cli构建和发布就像从Visual Studio构建和发布一样简单。 Visual Studio的发布正在对其发布进行完整的还原/构建，并且发布配置文件设置了<RuntimeIdentifier>。
我做错了几件事。我没有将-r win-x64包括在恢复和构建任务中，而是在使用dotnet publish --no-build。这就是不匹配的来源。接下来是在构建之后和发布之前我正在运行dotnet test。那是在清除一些需要发布的东西，但不确定是什么。
我将dotnet test更改为包括-p:RuntimeIdentifier=winx64，因为显然它使用-r来报告输出（显然他们在2.2中添加了-runtime）。
在此过程中我学到了一些知识，dotnet-cli不能与.sln文件（至少在构建代理程序中）兼容。文件锁和共享进程似乎有很大的问题。尝试优化构建任务以最大程度地减少dotnet-cli的工作量是一个大难题。
答案 1 :(得分：0)
我认为周杰伦在其他答案中对此做了介绍，但是为了弄清对我有用的东西，他正在奔跑：-
dotnet restore <path/to/.sln> -r linux-x64
在运行dotnet msbuild命令之前。 （显然将linux-x64替换为目标）。