Dotnet publish успешно на машине разработчика, агент сборки не работает, asp.net Netcoreapp2.1 / win-x64
В «Hosted VS2017» и агенте самостоятельной сборки (Windows Server 2012 R2) при запуске dotnet publish с указанным профилем публикации происходит сбой:
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.
На локальном сервере разработки (Win10, VS2017, много разных версий .net sdk), когда я публикую dotnet с той же самой командной строкой, все работает отлично.
Я перепробовал все: от обновления VS2017, установки точной версии SDK ядра .net и среды выполнения, на которую мы нацелены, обновления агента сборки, обновлений 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, восстановление dotnet с помощью сборки dotnet --no-restore, публикацию dotnet --no-build и т. д. То, на что он жалуется, не имеет смысла, особенно учитывая, что он отлично работает на моем машина разработчика. Какую еще информацию я могу предоставить, чтобы облегчить диагностику?
а когда вы переходите с -r win-s64 на dotnet publish? как вы вызывали публикацию с помощью профиля публикации?
Ответы 2
Оказывается, все дело в идентификаторе времени выполнения. Путаница возникла из-за того, что я предполагал, что сборка и публикация из dotnet-cli так же просты, как сборка и публикация из Visual Studio. Публикация Visual Studio выполняла полное восстановление / сборку с публикацией, а в профиле публикации был установлен <RuntimeIdentifier>.
Я делал несколько вещей неправильно. Я не включал -r win-x64 в задачи восстановления и сборки, а использовал dotnet publish --no-build. Вот откуда взялось одно несоответствие. Следующим было то, что я запускал dotnet test после сборки и перед публикацией. Это уничтожало некоторые вещи, которые требовались публикации, хотя не знаю, что именно.
Я изменил dotnet test, включив в него -p:RuntimeIdentifier=winx64, поскольку, очевидно, он использует -r для вывода отчетов (очевидно, они добавляют -runtime в 2.2).
Некоторые вещи, которые я узнал в процессе, dotnet-cli действительно ли НЕТ работает с файлами .sln, по крайней мере, в агенте сборки. Похоже, у него большая проблема с блокировками файлов и общими процессами. Попытка оптимизировать задачи сборки, чтобы свести к минимуму работу с dotnet-cli, является большой головной болью.
Я думаю, что Джей рассказал об этом в другом ответе, но, чтобы уточнить, что сработало для меня, я запустил: -
dotnet restore <path/to/.sln> -r linux-x64
непосредственно перед запуском команды dotnet msbuild. (Очевидно, замените linux-x64 своей целью).
Вы запускали восстановление пакета? Как выглядит ваш конвейер?