web-dev-qa-db-fra.com

Fichier d'assets project.assets.json introuvable lors de l'exécution d'une construction sur Azure Devops

J'ai un pipeline de génération configuré pour une solution Service Fabric sur Azure DevOps comme suit:

 Build tasks

Tout allait bien jusqu'à il y a quelques jours, lorsque la construction a commencé à échouer sur un agent de construction particulier (privé), avec l'erreur suivante (pour quelques projets):

C:\Program Files\dotnet\sdk\2.1.200\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets (327,5): Erreur: fichier d'actifs 'F:\Agent03\w\84\s\src\MyProject.Sam.Tiles.Domain\obj\project.assets.json 'introuvable. Exécutez une restauration de package NuGet pour générer ce fichier.

La tâche qui échoue est celle de Build solution $(PathToSolution).

Ce qui est étrange, c’est que la construction échoue lors de l’exécution de certains agents, mais avec d’autres, la construction est correcte.

Quelques détails:

  • La tâche Use NuGet 4.x a commencé à utiliser NuGet v4.9.1 très récemment, je pense. J'ai essayé d'utiliser la v4.8.1 sans succès;
  • La plupart des projets utilisent le format PackageReference, mais le projet .sfproj utilise le fichier packages.config.
  • J'ai essayé d'utiliser la tâche dotnet restore, mais une erreur s'est produite lors de la tentative de restauration des packages pour le projet .sfproj:

    ʻErreur: Impossible de trouver le '....\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props' fichier. S'il vous plaît restaurer le Nuget 'Microsoft.VisualStudio.Azure.Fabric.MSBuild'

Une idée sur ce qui pourrait causer ce problème?

4
Rui Jarimba

Certains projets utilisent le format PackageReference mais le projet .sfproj utilise le fichier packages.config.

Je ne comprends toujours pas pourquoi la construction a commencé à échouer, mais j'ai pu trouver une solution de contournement. Étant donné que PackageReference n'est pas encore pris en charge dans les projets Service Fabric, ma solution de contournement consistait à utiliser les tâches de restauration deux comme suit:

 Build tasks

2
Rui Jarimba

Le commentaire de Trevor sur 2/20 m'a donné l'indice. Vous n'avez probablement pas l'ensemble des projets référencés par la solution. (ProjectReferences peut aller à d'autres projets, qui ne sont pas dans la solution).

Voici pourquoi cette solution de contournement folle (exécuter les tâches de restauration de dotnet.exe et de nuget.exe) a fonctionné:

dotnet Restaurera les références de projet par défaut pour s'assurer qu'elles sont également restaurées. Le commutateur no-dependencies peut le désactiver.

la restauration de nuget.exe a la valeur opposée, car nous ne voulions pas supprimer les anciens utilisateurs. - récursif peut l'activer.

La bonne solution consiste à faire en sorte que votre solution contienne tous les projets.

-Rob Relyea Équipe client NuGet, responsable de l'ingénierie

1
Rob Relyea

Mon problème s'est avéré être une solution qui n'incluait pas tous les projets nécessaires.

J'ai un fichier de solution principal qui comprend all my projects, et un certain nombre de fichiers de solution plus petits avec seulement certains projets. La solution principale a été correctement conçue dans Azure DevOps, mais la solution partielle a échoué.

J'ai réalisé que le fichier project.assets.json manquant appartenait à un projet qui devait être inclus dans cette solution défaillante.

0
Trevor