Przywracasz odniesienia do Nuget?

Mam rozwiązanie i projekt w Visual Studio 2012.

Projekt ma plik packages.configw katalogu głównym projektu.

Na potrzeby tego pytania przyjmijmy, że przypadkowo usunąłem te biblioteki z Referencessekcji mojego projektu.

Podczas wchodzenia do menedżera pakietów NuGet interfejs nadal zgłasza zaznaczenie obok tych pakietów, wskazując, że są zainstalowane.

Jedynym sposobem, w jaki mogę zobaczyć, jak naprawić tę sytuację, jest usunięcie wszystkich wpisów packages.config, które naprawią problem interfejsu NuGet zgłaszającego je jako zainstalowane, i ponowne dodanie każdego z nich.

Czy istnieje mądrzejszy sposób? Miałem nadzieję, że włączenie opcji „włącz nuget w celu przywrócenia brakujących pakietów” rozwiąże ten problem, ale wydaje się, że nic nie robi.

Spróbuj ponownie zainstalować pakiety .

W konsoli menedżera pakietów NuGet wprowadź następującą komendę:

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

Jeśli chcesz ponownie zainstalować pakiety i przywrócić odwołania do całego rozwiązania, pomiń ten -ProjectNameparametr.

Aby przywrócić brakujący pakiet, konieczne jest włączenie przywracania pakietu NuGet na poziomie rozwiązania VS.

Gdyby to pomogło komuś, żadne z powyższych nie było wystarczające. Nadal nie mogłem zbudować, VS nadal nie mógł znaleźć referencji. Kluczem było po prostu zamknięcie i ponowne otwarcie rozwiązania po przywróceniu pakietów.

Oto scenariusz (przy użyciu programu Visual Studio 2012):

Otwierasz rozwiązanie, w którym brakuje pakietów. Odnośniki wskazują, że VS nie może ich znaleźć. Istnieje wiele sposobów przywracania brakujących pakietów, w tym

• budowanie rozwiązania z funkcją automatycznego przywracania
• otwierając konsolę Menedżera pakietów i klikając ładny przycisk „Przywróć”
• robienie tego, nuget restorejeśli masz zainstalowany wiersz poleceń

Ale bez względu na podejście, odniesienia te nadal będą wyświetlane jako brakujące. A kiedy zbudujesz, zawiedzie. Westchnienie. Jednak jeśli zamkniesz to rozwiązanie i otworzysz je ponownie, teraz VS ponownie sprawdzi te ładne <HintPath>, stwierdzi, że paczki wróciły tam, gdzie należą i wszystko jest w porządku ze światem.

Aktualizacja

Czy program Visual Studio nadal nie widzi, że masz pakiet? Nadal wyświetlasz referencję, której nie można rozwiązać? Upewnij się, że wersja przywróconego pakietu jest dokładnie taka sama jak <HintPath>w pliku .csproj. Nawet niewielki numer poprawki błędu (np. 1.10.1 do 1.10.2) spowoduje, że odwołanie nie powiedzie się. Możesz to naprawić albo bezpośrednio edytując plik csproj xml, albo usuwając odwołanie i tworząc nowy, wskazując na nowo przywróconą wersję w katalogu pakietów.

Chociaż rozwiązanie dostarczone przez @jmfenoll działa, aktualizuje się do najnowszych pakietów. W moim przypadku po zainstalowaniu wersji beta2 (wersja wstępna) zaktualizowałem wszystkie biblioteki lib do wersji RC1 (która zawierała błąd). Zatem powyższe rozwiązanie wykonuje tylko połowę pracy.

Jeśli jesteś w takiej samej sytuacji jak ja i chciałbyś zsynchronizować swój projekt z dokładną wersją pakietów NuGet, które posiadasz / lub określiłeś w swoim packages.config, wtedy ten skrypt może ci pomóc. Wystarczy skopiować i wkleić go do konsoli Menedżera pakietów

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
    }
  }
}

A następnie uruchom go albo z osobną nazwą pakietu jak

Sync-References AutoMapper

lub dla wszystkich pakietów takich jak

Sync-References

Kredyty trafiają do Dana Haywooda i jego posta na blogu .

Poniższy skrypt można uruchomić w oknie konsoli Menedżera pakietów i usunie wszystkie pakiety z każdego projektu w rozwiązaniu przed ich ponowną instalacją.

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
    }
}

Spowoduje to ponowne uruchomienie skryptu instalacyjnego każdego pakietu, co powinno przywrócić brakujące odwołania do zestawu. Niestety, wszystkie inne rzeczy, które mogą wykonywać skrypty - takie jak tworzenie plików i modyfikowanie konfiguracji - również się powtórzą. Prawdopodobnie będziesz chciał zacząć od czystej kopii roboczej i użyć narzędzia SCM, aby wybrać i wybrać zmiany w projekcie, które chcesz zachować, a które zignorować.

Ręcznie dodałem biblioteki DLL. Kliknij prawym przyciskiem myszy Odniesienia w projekcie, wybierz Dodaj odniesienie, a następnie w oknie dialogowym naciśnij przycisk Przeglądaj. Biblioteki DLL NuGet znajdują się w katalogu pakietów rozwiązania. Aby uzyskać ich nazwy, kliknij prawym przyciskiem myszy odniesienia w innym projekcie, który działa poprawnie, wybierz właściwości i spójrz na właściwość ścieżki.

W Visual Studio 2015 (Soulution jest pod kontrolą źródła, MVC-Project), csano Update-Package -Reinstall -ProjectName Your.Project.Namedziałało, ale pomieszało się z kilkoma blokadami zapisu.

Wcześniej musiałem ręcznie usunąć „paczki” - Folder. (Wyglądało na to, że jest zablokowany z powodu kontroli źródła).

Musiałem także ponownie zainstalować pakiet MVC z Menedżera pakietów NuGet.

Ten skrypt ponownie zainstaluje wszystkie pakiety projektu bez zakłócania zależności lub instalowania zależności, które mogły zostać celowo usunięte. (Więcej dla twórców pakietów części).

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

Na wypadek, gdyby to komuś pomogło - w moim scenariuszu mam kilka wspólnych bibliotek (które mają własne projekty / rozwiązania TFS) wszystkie połączone w jedno rozwiązanie.

Nuget pomyślnie przywróci projekty, ale brakuje biblioteki DLL.

Podstawowym problemem było to, że chociaż twoje rozwiązanie ma własny folder pakietów i poprawnie je przywróciło do tego folderu, plik projektu (np. Csproj) odnosi się do innego projektu, który może nie zostać pobrany. Otwórz plik w edytorze tekstu, aby zobaczyć, skąd pochodzą twoje referencje.

Może się to zdarzyć podczas zarządzania pakietami w różnych połączonych rozwiązaniach współdzielonych - ponieważ prawdopodobnie chcesz się upewnić, że wszystkie biblioteki DLL są na tym samym poziomie, możesz ustawić to na najwyższym poziomie. Oznacza to, że czasami będzie szukał zupełnie innego rozwiązania dla biblioteki DLL, do której się odwołuje, więc jeśli nie masz pobranych i aktualnych projektów / rozwiązań, możesz otrzymać powyższy problem.

Muszę zgodzić się z @Juri, że niezwykle popularna odpowiedź jmfenoll nie jest kompletna. W przypadku uszkodzonych referencji twierdzę, że przez większość czasu nie chcesz aktualizować do najnowszego pakietu, a jedynie naprawiać swoje referencje do bieżących wersji, których używasz. I Juri zapewnił przydatną funkcję, Sync-Referencesaby to zrobić.

Ale możemy pójść jeszcze dalej, pozwalając na elastyczność filtrowania według projektu, a także pakietu:

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
        }
    }
}

Miałem ten sam problem z brakującymi referencjami. Poniżej mojego scenariusza:

• Świeży komputer z systemem Windows 10 i instalacja VS Community 2015
• Właśnie sprawdziłem kod repozytorium za pośrednictwem TFS
• Jedno rozwiązanie zostało zbudowane dobrze, jedno miało jeden projekt z brakującymi referencjami (EF, System.Http, jako instancja), ale odpowiednie pakiety nuget zostały poprawnie zainstalowane.

Wszystkie numery wersji w projekcie i pakietach pasują do siebie, przywracanie nugetu (na wszystkie sposoby) nie działało.

Jak to naprawiłem: po prostu usuń foldery pakietów w katalogu głównym rozwiązania i uruchom przywracanie nuget. W tym momencie pliki DLL są poprawnie pobierane i można je dodawać do brakujących odniesień.

Zbyt często cierpiałem z powodu tego problemu, w moim przypadku pobranie brakującego NuGet zostało sprawdzone (ale nie przywraca go) i nie mogę odinstalować i ponownie zainstalować, ponieważ zmodyfikowałem niektóre z zainstalowanych pakietów ... więc:

Właśnie wyczyściłem pamięć podręczną i przebudowałem ją i zadziałała. (Narzędzia-Opcja-Menedżer pakietów Nuget - Ogólne)

również ten link pomaga https://docs.nuget.org/consume/package-restore/migrating-to-automatic-package-restore .

1. Skopiuj plik pakiety.config projektu i zastosuj wszystkie modyfikacje wersji

2. Unistall wszystkie pakiety i usuń zależności

   $packages = Get-Package -ProjectName [nameOfProjectToRestore]
   foreach ($package in $packages) {
       uninstall-package  -projectname [nameOfProjectToRestore] -id $package.Id -version $package.version -RemoveDependencies -force ;
   }
   

3. Wyczyść folder paczek w katalogu głównym projektu

4. Skopiuj modyfikacje package.config do folderu głównego witryny

5. Uruchom ten kod, aby przywrócić projekt

   $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
   }