dotnet publish succeeds on dev machine, build agent fails, asp.net Netcoreapp2.1/win-x64

Question

On "Hosted VS2017" and self-hosted build agent (Windows Server 2012 R2), running dotnet publish with a publish profile specified fails with:

C:\Program Files\dotnet\sdk\2.1.502\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5): error NETSDK1047: Assets file 'C:\agent_work\11\s\\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.1/win-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.

On local dev server (Win10, VS2017, many different .net sdk versions) when I dotnet publish with the exact same command line, everything works great.

I have tried everything from updating VS2017, installing the exact version of .net core SDK and runtime that we're targeting, updating the build agent, windows updates... Nothing seems to help. I can't understand why it's having different behavior.

The publish profile is a FileSystem profile and has the following two elements specified:

<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>

The command line looks this: "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

Does anyone have a clue what I can do to get this working?

Answer 1

This turns out to be all about the Runtime Identifier. The confusion arose because I assumed building and publishing from dotnet-cli was as simple as building and publishing from Visual Studio. Visual Studio's publish was doing a full restore/build with its publish, and the publish profile had the <RuntimeIdentifier> set.

I was doing several things wrong. I wasn't including -r win-x64 to the restore and build tasks, and I was using dotnet publish --no-build. So that's where one mismatch came from. The next was that I was running dotnet test after build and before publish. That was wiping out some things that publish needed, not sure what though.

I changed dotnet test to include -p:RuntimeIdentifier=winx64 since apparently it uses -r for reporting output (apparently they're adding -runtime in 2.2).

Some things I learned in the process, dotnet-cli does NOT work well with .sln files, at least in build agent's. It seems to have a big problem with file locks and shared processes. Trying to optimize build tasks to minimize work with the dotnet-cli is a major pain in the ass.

Answer 2

I think Jay covered this in the other answer, but to clarify what worked for me was running:-

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

just before running the dotnet msbuild command. (Obviously replace linux-x64 with your target).