Моя версия этой проблемы (я думаю) была вызвана сочетанием реальных версий .NET Core, установленных на сервере сборки Jenkins вместе с проектом Unit Test, имеющим неоднозначные ссылки.
Я понимаю, что в идеальном случае dotnet не ожидает версии, указанной в csproj для AspNetCore - обеспечивая максимальную гибкость при сборке:
<PackageReference Include="Microsoft.AspNetCore.App" />
Однако на сервере сборки, когда он компилировал основной проект (первый), он решил использовать 2.1.6 в качестве версии AspNetCore. Затем он пытается скомпилировать тестовый проект, и этот проект имеет минимальную версию «2.1.1», поэтому процесс сборки пытается понизить версию, а затем прервать сборку в случае сбоя.
Я удалил минимальную версию «2.1.1» из тестового проекта, но тогда тестовый проект не будет собираться локально, потому что он не мог однозначно разрешить зависимости. После ряда обновлений / понижений в пакете NuGet не было никакой радости, поэтому мы решили установить минимальную версию "2.1.6", чтобы она соответствовала серверу сборки.
Это все еще не могло локально разрешить все зависимости корректно, и, в конце концов, также принудительно установило минимальную версию для NetCore:
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.6" />
<PackageReference Include="Microsoft.NetCore.App" Version="2.1.6" />
Все теперь построено локально и на сервере сборки Jenkins!