Restauration des références Nuget?


182

J'ai une solution et un projet dans Visual Studio 2012.

Le projet a un fichier packages.configà la racine du projet.

Pour les besoins de cette question, supposons que j'ai accidentellement supprimé ces bibliothèques du References section de mon projet.

Lorsque vous accédez au gestionnaire de packages NuGet, l'interface signale toujours une coche à côté de ces packages, indiquant qu'ils sont installés.

La seule façon dont je peux voir comment résoudre cette situation est de supprimer toutes les entrées de packages.config , ce qui résoudra le problème de l'interface NuGet les signalant comme installées et de les ajouter à nouveau.

Y a-t-il un moyen plus intelligent? J'avais espéré que l'activation de «activer nuget pour restaurer les paquets manquants» résoudrait ce problème, mais cela ne semble rien faire.

Réponses:


329

Essayez de réinstaller les packages .

Dans la console NuGet Package Manager, entrez la commande suivante:

Update-Package -Reinstall -ProjectName Your.Project.Name

Si vous souhaitez réinstaller les packages et restaurer les références pour l'ensemble de la solution, omettez le -ProjectNameparamètre.


10
Traduction française du lien: translate.google.com/...
Csaba Toth

18
Remarque: cette commande réinstalle les références sur tous les projets actuellement ouverts dans Visual Studio, plutôt que sur le projet sélectionné dans la console.
simbolo

3
Cette commande réinstallera les packages dans toute la solution, pas seulement dans un projet sélectionné!
Alex Sorokoletov

14
Extrêmement dangereux !!!! Si le processus est interrompu, vous perdrez toutes les références de vos packages et devrez en ajouter une par une à chaque projet de votre solution.
Bill Velasquez

2
@BillVelasquez cette chose a juste mangé toutes mes références. Eh bien, dieu merci pour git, je suppose.
Gleno


13

Au cas où cela aiderait quelqu'un, pour moi, rien de ce qui précède n'était suffisant. Je ne pouvais toujours pas construire, VS ne pouvait toujours pas trouver les références. La clé était simplement de fermer et de rouvrir la solution après la restauration des packages.

Voici le scénario (à l'aide de Visual Studio 2012):

Vous ouvrez une solution dont les packages sont manquants. Les références montrent que VS ne peut pas les trouver. Il existe de nombreuses façons de restaurer les packages manquants, notamment

  • création d'une solution configurée pour la restauration automatique
  • ouvrir la console du gestionnaire de packages et cliquer sur le joli bouton "Restaurer"
  • faire nuget restoresi vous avez installé le nuget de ligne de commande

Mais quelle que soit l'approche, ces références seront toujours indiquées comme manquantes. Et quand vous construisez, cela échouera. Soupir. Cependant, si vous fermez la solution et la rouvrez, VS vérifie maintenant ces bons<HintPath> , constate que les packages sont de retour à leur place, et tout va bien dans le monde.

Mettre à jour

Visual Studio ne voit toujours pas que vous avez le package? Vous affichez toujours une référence qu'il ne peut pas résoudre? Assurez-vous que la version du package que vous avez restaurée est exactement la même que celle <HintPath>de votre fichier .csproj. Même un numéro de correction de bogue mineur (par exemple 1.10.1 à 1.10.2) entraînera l'échec de la référence. Vous pouvez résoudre ce problème soit en éditant directement votre xml csproj, soit en supprimant la référence et en en créant une nouvelle pointant vers la version nouvellement restaurée dans le répertoire packages.


1
Vous faites un point très important sur la restauration en vous assurant uniquement que les packages sont dans le dossier du package (qui bien sûr peut être à plusieurs endroits). Cependant, la fermeture et la réouverture ne fonctionnaient toujours pas pour moi, même avec les versions de package correctes, j'ai fini par devoir modifier manuellement les chemins d'indication dans chaque fichier csproj. Je pense que cela est dû au déplacement du dossier du package par rapport au projet.
Shaun

Modifier le .csprojfichier pour s'assurer que les numéros de version correspondent a fonctionné pour moi. Merci!
Mateen Ulhaq

11

Alors que la solution fournie par @jmfenoll fonctionne, elle se met à jour avec les derniers packages. Dans mon cas, après avoir installé beta2 (pré-version), il a mis à jour toutes les bibliothèques vers RC1 (qui avait un bogue). Ainsi, la solution ci-dessus ne fait que la moitié du travail.

Si vous êtes dans la même situation que moi et que vous souhaitez synchroniser votre projet avec la version exacte des packages NuGet que vous avez / ou spécifiés dans votre packages.config, alors, ce script pourrait vous aider. Copiez-le simplement et collez-le dans votre console du gestionnaire de packages

function Sync-References([string]$PackageId) {
  get-project -all | %{
    $proj = $_ ;
    Write-Host $proj.name; 
    get-package -project $proj.name | ? { $_.id -match $PackageId } | % { 
      Write-Host $_.id; 
      uninstall-package -projectname $proj.name -id $_.id -version $_.version -RemoveDependencies -force ;
      install-package -projectname $proj.name -id $_.id -version $_.version
    }
  }
}

Et puis exécutez-le soit avec un nom de package distinct comme

Sync-References AutoMapper

ou pour tous les packages comme

Sync-References

Les crédits vont à Dan Haywood et à son article de blog .


8

Le script suivant peut être exécuté dans la fenêtre de la console Package Manager et supprimera tous les packages de chaque projet de votre solution avant de les réinstaller.

foreach ($project in Get-Project -All) { 
    $packages = Get-Package -ProjectName $project.ProjectName
    foreach ($package in $packages) {
        Uninstall-Package $package.Id -Force -ProjectName $project.ProjectName
    }
    foreach ($package in $packages) {
        Install-Package $package.Id -ProjectName $project.ProjectName -Version $package.Version
    }
}

Cela exécutera à nouveau le script d'installation de chaque package, ce qui devrait restaurer les références d'assembly manquantes. Malheureusement, toutes les autres choses que les scripts d'installation peuvent faire - comme la création de fichiers et la modification des configurations - se reproduiront également. Vous voudrez probablement commencer avec une copie de travail propre et utiliser votre outil SCM pour sélectionner et choisir les modifications à conserver dans votre projet et celles à ignorer.


3

J'ai ajouté les DLL manuellement. Cliquez avec le bouton droit sur Références dans le projet, sélectionnez Ajouter une référence, puis dans la boîte de dialogue, appuyez sur le bouton Parcourir. Les DLL NuGet se trouvent dans le répertoire packages de la solution. Pour obtenir leurs noms, vous pouvez cliquer avec le bouton droit sur les références d'un autre projet qui fonctionne correctement, sélectionner les propriétés et rechercher dans la propriété path.


C'est la solution la plus simple. Cela fonctionne pour moi en parcourant simplement le dossier packages.
Hao Nguyen

2

Dans Visual Studio 2015 (Soulution est sous contrôle de code source, MVC-Project), csano a Update-Package -Reinstall -ProjectName Your.Project.Namefonctionné, mais il a gâché certains verrous d'écriture.

J'ai dû supprimer le dossier "packages" manuellement avant. (Il semblait verrouillé à cause du contrôle de source).

De plus, j'ai dû réinstaller le package MVC à partir du gestionnaire de packages NuGet.


2

Ce script réinstallera tous les packages d'un projet sans gâcher les dépendances ou installer des dépendances qui auraient pu être supprimées intentianlyz. (Plus pour leurs développeurs de packages de partie.)

Update-Package -Reinstall -ProjectName Proteus.Package.LinkedContent -IgnoreDependencies

1

Juste au cas où cela aiderait quelqu'un - Dans mon scénario, j'ai des bibliothèques partagées (qui ont leurs propres projets / solutions TFS) toutes combinées en une seule solution.

Nuget restaurerait les projets avec succès, mais la DLL serait manquante.

Le problème sous-jacent était que, bien que votre solution ait son propre dossier de packages et les ait correctement restaurés dans ce dossier, le fichier de projet (par exemple .csproj) fait référence à un projet différent sur lequel le package peut ne pas être téléchargé. Ouvrez le fichier dans un éditeur de texte pour voir d'où viennent vos références.

Cela peut se produire lors de la gestion de packages sur différentes solutions partagées interconnectées - puisque vous souhaitez probablement vous assurer que toutes les DLL sont au même niveau, vous pouvez définir cela au niveau supérieur. Cela signifie que parfois il recherchera une solution complètement différente pour une DLL référencée et donc si vous n'avez pas tous les projets / solutions téléchargés et à jour, vous pouvez rencontrer le problème ci-dessus.


1

Je suis d'accord avec @Juri pour dire que la réponse très populaire de jmfenoll n'est pas complète. Dans le cas de références cassées, je soumets que la plupart du temps , vous ne pas à mettre à jour le dernier paquet, mais seulement corriger vos références aux actuelles versions que vous arrive d'utiliser. Et Juri a fourni une fonction pratique Sync-Referencespour faire exactement cela.

Mais nous pouvons aller un peu plus loin, permettant la flexibilité de filtrer par projet ainsi que par package:

function Sync-References([string]$PackageId, [string]$ProjectName) {
    get-project -all | 
    Where-Object { $_.name -match $ProjectName } |
    ForEach-Object {
        $proj = $_ ;
        Write-Output ('Project: ' + $proj.name)
        Get-Package -project $proj.name |
        Where-Object { $_.id -match $PackageId } |
        ForEach-Object { 
            Write-Output ('Package: ' + $_.id)
            uninstall-package -projectname $proj.name -id $_.id -version $_.version -RemoveDependencies -force
            install-package -projectname $proj.name -id $_.id -version $_.version
        }
    }
}

1

J'ai eu le même problème avec des références manquantes. Ci-dessous mon scénario:

  • Installation de la nouvelle machine Windows 10 et de VS Community 2015
  • Je viens de vérifier le code du référentiel via TFS
  • Une solution construite très bien, une solution avait un projet avec des références manquantes (EF, System.Http, par exemple), mais les packages de nuget relatifs étaient correctement installés.

Tous les numéros de version du projet et des packages correspondent, la restauration de nuget (de toutes ses manières) ne fonctionnait pas.

Comment je l'ai résolu: supprimez simplement les dossiers de packages dans la racine de la solution et exécutez la restauration de nuget. À ce stade, les dll sont correctement téléchargées et peuvent être ajoutées pour les références manquantes.



0
  1. Copier le fichier packages.config du projet et appliquer toutes les modifications de version
  2. Désinstaller tous les packages et supprimer les dépendances

    $packages = Get-Package -ProjectName [nameOfProjectToRestore]
    foreach ($package in $packages) {
        uninstall-package  -projectname [nameOfProjectToRestore] -id $package.Id -version $package.version -RemoveDependencies -force ;
    }
    
  3. Effacez le dossier packages à la racine du projet

  4. Copiez le package.config modifie dans le dossier racine du site Web

  5. Exécutez ce code pour restaurer le projet

    $packages = Get-Package -ProjectName [nameOfProjectToRestore]
    foreach ($package in $packages) {
        uninstall-package  -projectname [nameOfProjectToRestore] -id $package.Id -version $package.version -RemoveDependencies -force ;
    }
    foreach ($package in $packages) {
        install-package  $package.Id -ProjectName [nameOfProjectToRestore] -Version $package.Version
    }
    
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.