Brakujący pakiet powoduje niepowodzenie przywracania pakietu NuGet

Question

Jesteśmy entuzjastycznym użytkownikiem NuGet, zarówno dla pakietów wewnętrznych, jak i zewnętrznych.

Niedawno zaczęliśmy włączać opcję Przywracania pakietów NuGet w niektórych z naszych projektów kompilacji, aby zmniejszyć liczbę plików binarnych, które zatwierdzamy do kontroli źródła, ale mamy problem.

Widzimy, że Visual Studio zajmuje naprawdę dużo czasu, aby rozpocząć, a gdy już się uruchomi (może to zająć ponad pół godziny), kolejna kompilacja jest równie czasochłonna. Podczas gdy tak się dzieje, można zobaczyć wiele procesów potomnych NuGet pojawiających się i umierających w eksploratorze procesów.

Zauważyliśmy, że jeśli wersja pakietu, do którego odwołuje się plik packages.config, nie jest dostępna z żadnego ze skonfigurowanych źródeł pakietów (być może jest to stara wersja pakietu wewnętrznego i ktoś pomocny został oczyszczony nasze lokalne repozytorium), wydaje się, że NuGet i Visual Studio wchodzą w coś w rodzaju nieskończonej (lub co najmniej długotrwałej) pętli retry.

Jeżeli możemy uruchomić komendę Nuget zainstalować z wiersza poleceń wrócimy Błąd

>.nuget\NuGet.exe install project\packages.config -o packages 
Unable to find version '1.0.0.1' of package 'my.internal.package'. 

ale wydaje się, że to nie jest spożywane poprawnie przez Visual Studio/Nuget.

• Czy NuGet rejestruje swoje działania w dowolnym miejscu?
• możemy ograniczyć Nuget przywrócić ponownych prób lub limitu czasu (być może w pliku nuget.targets?)
• Wygląda jakby semantyczny wersjonowanie Nuget nie jest używany, ponieważ w naszym powyższym scenariuszu 1.0.0.2 jest dostępna z repo , czy można to włączyć?

Answer 1

To wydaje się podobna do tej kwestii http://nuget.codeplex.com/workitem/2970 tymczasowe obejście pracował dla mnie jest otwarcie nuget.targets i zastąpić
< - Musimy zapewnić pakiety zostaną przywrócone przed zdecydowaniem montażowej ->
< ResolveReferencesDependsOn Condition = "$ (RestorePackages) ==" true "">
RestorePackages;
$ (ResolveReferencesDependsOn);
</ResolveReferencesDependsOn>
z

< BuildDependsOn Stan = "$ (RestorePackages) == 'true'">
RestorePackages;
$ (BuildDependsOn);
</BuildDependsOn>

Zamknij i przeładuj roztwór w VS. to spowodowałoby, że kompilacja będzie zależała od pakietów przywracania, a nie od montażu, co wydaje się rozwiązać problem.

mam nadzieję, że to pomoże.

Answer 2

Po pierwsze Twoja wersja nie jest zgodna z poleceniami nuget, tzn. 1.2.3. Powinieneś więc spróbować użyć wersji 1.0.1, aby sprawdzić, czy to rozwiązuje problem.

• Czy NuGet rejestruje swoje działania w dowolnym miejscu?

Możesz użyć flagi -verbosity w linii poleceń "nuget install", aby uzyskać dodatkowe informacje. Szczegóły są również dostępne w oknie wyjściowym. Wybierz "menedżer pakietów" z menu rozwijanego. Więcej użytku devenv/log

• możemy ograniczyć Nuget przywrócić ponownych prób lub limitu czasu (być może w nuget.targets plik?)

nie wiem o żadnym tutaj.

• Wygląda jakby semantyczny wersjonowanie Nuget nie jest używany, ponieważ w naszym powyżej scenariusz 1.0.0.2 jest dostępna z repo, można to być włączony?

Można to osiągnąć, zaznaczając opcję "automatycznie sprawdzaj aktualizacje" w narzędziach-> Opcje-> Menedżer pakietów? Sprawdź, czy plik packages.config ogranicza wersję do 1.0.0.1