dotnet 在开发机器上发布成功，构建代理失败，asp.net Netcoreapp2.1/win-x64答案

【问题标题】：dotnet publish succeeds on dev machine, build agent fails, asp.net Netcoreapp2.1/win-x64dotnet 在开发机器上发布成功，构建代理失败，asp.net Netcoreapp2.1/win-x64
【发布时间】：2019-05-16 20:09:04
【问题描述】：

在“托管 VS2017”和自托管构建代理 (Windows Server 2012 R2) 上，使用指定的发布配置文件运行 dotnet publish 失败：

C:\程序 Files\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,Version=v2.1/win-x64' 的目标。确保还原具有运行并且您已在 TargetFrameworks 中包含“netcoreapp2.1” 为您的项目。您可能还需要在您的项目的 RuntimeIdentifiers。

在本地开发服务器（Win10、VS2017、许多不同的 .net sdk 版本）上，当我使用完全相同的命令行进行 dotnet 发布时，一切正常。

我已经尝试了一切，从更新 VS2017、安装我们所针对的 .net 核心 SDK 和运行时的确切版本、更新构建代理、Windows 更新......似乎没有任何帮助。我不明白为什么它有不同的行为。

发布配置文件是一个文件系统配置文件，并指定了以下两个元素：

<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

有没有人知道我可以做些什么来让它工作？

【问题讨论】：

您是否运行了包还原？您的管道是什么样的？
我已经将管道简化为简单地获取代码和运行 dotnet cli 任务。我尝试了 dotnet build、dotnet restore 和 dotnet build --no-restore 和 dotnet publish --no-build 等。它抱怨的东西没有意义，特别是考虑到它在我的开发机。我还可以提供哪些其他信息来帮助诊断？
当您将-r win-s64 传递给dotnet publish 时？您是如何使用发布配置文件调用发布的？

标签： asp.net-core msbuild .net-core azure-devops azure-pipelines

【解决方案1】：

我认为 Jay 在另一个答案中涵盖了这一点，但为了澄清对我有用的是运行：-

dotnet restore <path/to/.sln> -r linux-x64

就在运行dotnet msbuild 命令之前。（显然用你的目标替换linux-x64）。

【讨论】：

【解决方案2】：

事实证明这都是关于运行时标识符的。因为我认为从 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 的工作是一件令人头疼的事情。

【讨论】：