Публикация dotnet успешно выполняется на компьютере разработчика, сбой агента сборки, asp.net Netcoreapp2.1 / win-x64 - PullRequest
Новая
       30

Публикация dotnet успешно выполняется на компьютере разработчика, сбой агента сборки, asp.net Netcoreapp2.1 / win-x64

0 голосов
/ 16 декабря 2018

В «Hosted VS2017» и агенте самостоятельной сборки (Windows Server 2012 R2) при запуске dotnet publish с указанным профилем публикации происходит сбой:

C: \ Program Files \ dotnet \sdk \ 2.1.502 \ Sdks \ Microsoft.NET.Sdk \ target \ Microsoft.PackageDependencyResolution.targets (198,5): ошибка NETSDK1047: файл ресурсов 'C: \ agent_work \ 11 \ s \\ obj \ project.assets.jsonУ 'нет цели для' .NETCoreApp, версия = v2.1 / win-x64 '.Убедитесь, что восстановление выполнено и что вы включили «netcoreapp2.1» в TargetFrameworks для вашего проекта.Вам также может понадобиться включить win-x64 в RuntimeIdentifiers вашего проекта.

На локальном сервере dev (Win10, VS2017, много разных версий .net sdk), когда я публикую dotnet точно такой же командойлиния, все отлично работает.

Я пробовал все, начиная с обновления VS2017, установки точной версии .net core 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

Кто-нибудь знает, что я могу сделать, чтобы это работало?

1 Ответ

0 голосов
/ 17 декабря 2018

Оказывается, все дело в идентификаторе времени выполнения.Путаница возникла из-за того, что я предполагал, что создавать и публиковать из 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 - большая проблема в заднице.

...