web-dev-qa-db-fra.com

Nuget Update-Package ne reconnaît pas le package installé -> La mise à jour a échoué

J'ai installé un paquet NuGet (que nous avons développé dans le projet) dans un projet VS. Quand je lance Update-Package sur le projet Nuget, je reçois:

Update-Package : 'Project name' was not installed in any project. Update failed.
At line:1 char:15
+ Update-Package <<<<  Project name
    + CategoryInfo          : NotSpecified: (:) [Update-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UpdatePackageCommand

J'ai vérifié dans le fichier package.config que le package NuGet est bien défini. Des indices?

nuget
41
Tomas Jansson

Je travaille sur le même projet que Tomas et j'ai essayé de comprendre quand ce problème se produit et pourquoi. Il semble que cela se produise lorsque nous avons une ou plusieurs anciennes versions d’un paquet dans le dossier des paquets et que nous essayons d’émettre la commande 'update-package'. 

Avant d’émettre la commande, notre dossier packages et notre configuration ressemblent à ceci:

Dossier Packages:

Common.WebApi.1.0.0.109
Common.WebApi.1.0.0.110

Paquets config:

<packages>
    <package id="Common.WebApi" version="1.0.0.110" />
    <package id="System.Json" version="4.0.20126.16343" />
    <package id="System.Net.Http" version="2.0.20126.16343" />
</packages>

Maintenant, en lançant 'update-package Common.WebApi', nous obtenons l'erreur suivante:
Package de mise à jour: 'OPF.Common.WebApi' n'a été installé dans aucun projet. Mise à jour a échoué.

Pour résoudre ce problème, je supprime l'ancien paquet «Common.WebApi.1.0.0.109» du dossier des paquets et relançai la commande, qui fonctionnera ensuite. 

La question évidente est: pourquoi ai-je un ancien paquet dans mon dossier de paquets? Cela nous arrive parce que nous n’engageons pas nos propres paquets dans le contrôle de source. Au lieu de cela, nous utilisons l'approche décrite ici: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

Le «vieux problème de paquet» se produit dans cette situation:
1. Developer A met à jour un package et valide le package.config dans le contrôle de source
2. Le développeur B obtient la dernière version du contrôle de code source et reçoit le package.config mis à jour.
3. Le développeur B construit le projet et le nouveau package est créé dans son dossier de packages.
4. Nuget ne supprime pas l'ancien package du développeur B de son dossier packages. Le développeur B a donc maintenant l'ancien package et le nouveau package dans son dossier packages, mais uniquement une référence dans le package.config à la nouvelle version.

Pour moi, il semble que Nuget ne s’attende pas à ce qu’il existe plusieurs versions d’un paquet dans le dossier des paquets et cela devient confus lorsque vous essayez de mettre à jour un paquet qui a plusieurs versions [dans le dossier des paquets] bien que vous fassiez seulement référence à un seul paquet de package.config.

49
Mats Mortensen

J'ai eu un problème très similaire récemment - il s'est avéré que packages/repositories.config était manquant (car nous ne validons pas le dossier packages). J'ai fait quelque chose dans VS (en ajoutant éventuellement un nouveau package à un projet) qui a amené VS à régénérer le fichier repositories.config répertoriant tous les packages de tous les projets. Après cela, la mise à jour a bien fonctionné.

5
Danny Tuppeny

J'ai eu le même problème. Nous ne vérifions pas le dossier des packages (la tâche de génération de nuget télécharge tous les packages).

Le seul moyen pour moi de résoudre le problème était de supprimer le dossier des packages, puis de reconstruire le projet.

3
jgauffin

Voici comment j'ai réussi à obtenir la dernière version du gestionnaire de paquets:

  1. Démarrer VS2010 en mode administrateur (exécuté en tant qu'administrateur)
  2. Outils> Ajouter au gestionnaire> Désinstaller NuGet
  3. Redémarrer Visual Studio
  4. Installer NuGet

Voila!

J'espère que cela t'aides.

2
Saksham

Une autre façon, cela peut se produire:

  1. PAS de paquets en cours de restauration (utilisation de ReSharper 2016.2 Build, par exemple)
  2. Essayez de mettre à jour alors que la version du paquet en question n’existe PAS dans/packages /

Pour réparer, exécutez les packages de restauration d'une manière ou d'une autre

0
Thymine