Файл ресурсов project.assets.json не найден при запуске сборки в Azure Devops

У вас есть соответствующий .tfignore / .gitignore (в зависимости от того, какой вы используете для управления версиями), который исключает папки bin, obj и packages? Можете ли вы подтвердить, что эти папки не находятся в системе контроля версий?

В корневой папке находится файл .gitignore. Я считаю, что он используется по умолчанию для Visual Studio с некоторыми изменениями minro. Да, есть правила для bin, obj и **/packages/* (nuget)

Кто-то переопределил .gitignore и случайно передал их в систему контроля версий?

@DanielMann вы имеете в виду пакеты nuget? Нет, пакеты не находятся под контролем источника.

CI использует чистую копию исходников? Вы пытались проверить чистую копию на своем локальном компьютере и восстановить + построить решение?

@OlegKarasik да чистю исходники - в выпадающем списке All build directories выбран Clean options. Эта сборка дает сбой только при использовании определенных агентов, и она была запущена всего несколько дней назад.

Поскольку это частный агент сборки, есть ли у вас к нему удаленный доступ? Можете ли вы проверить, что все каталоги действительно удалены (или удалите их вручную)? Подобная ошибка случилась с моим локальным ящиком несколько раз, и всегда была связана с неудаленными вещами.

@OlegKarasik да, у меня есть удаленный доступ к виртуальной машине частного агента. Я могу попробовать, даже если я не уверен, какие папки удалить? Кроме того, я не совсем уверен, что это будет иметь значение, потому что агент, похоже, создает новую папку для каждой сборки (например, F:\Agent01\w\499\s)

вы можете попробовать добавить этап сборки для выполнения msbuild /t:restore в дополнение к восстановлению nuget. msbuild /t:restore не будет работать с проектами packages.config. Я думаю, что nuget.exe подойдет для «классических» проектов csproj, использующих PackageReference, но я действительно не уверен в проектах SDK. Хотя я думал, что создание проектов SDK автоматически восстанавливает их, я удивлен, что это не работает автоматически.

Не случайно ли в вашем репозитории несколько решений, и MyProject.Sam.Tiles.Domain не входит ни в одно из них, а в другом проекте решения есть ссылка на MyProject.Sam.Tiles.Domain?

@Ziv Я могу подтвердить, что в этом репозитории есть 2 решения. Я не уверен насчет ссылок, мне нужно спросить об этом у группы разработчиков, которая отвечает за этот репозиторий.

@Ziv, запускающий обе задачи восстановления (стандартное восстановление и восстановление сети), поможет, но я пытаюсь понять, почему эта проблема началась всего несколько дней назад и почему сборка не прерывается при использовании некоторых агентов?

Вы можете попробовать добавить nuget.exe -version и dotnet --info в журналы сборки, чтобы проверить, установлены ли разные версии или разные SDK на разных агентах. Вы также можете попробовать поискать / открыть проблему на NuGet / Главная, где кто-то умнее меня может дать лучшее понимание.

@Ziv Я могу подтвердить, что в обоих решениях есть ссылки на разные проекты.

Я знаю, что nuget нужно восстановить каждый проект в графе зависимостей. Я считаю, что создание решения в Visual Studio не будет создавать или восстанавливать проекты, не входящие в решение, даже если проект в решении имеет ссылку на проект, но я не знаю, имеет ли msbuild такое же ограничение. Я подозреваю, что да, потому что Visual Studio активно использует MSBuild. Если это тот случай, с которым вы столкнулись, это известная проблема / по своей природе. Однако он не отвечает на вопрос, почему изменилось поведение.

Восстановление NuGet должно быть достаточным, поскольку оно работает как для PackageReference, так и для packages.config. В противном случае может быть проблема. Был бы признателен, если бы вы могли подать проблему с некоторым воспроизведением на github.com/NuGet/Home/issues