Rozwiązanie do retargetingu z .Net 4.0 do 4.5 - jak ponownie przekierować pakiety NuGet?

205

Przeprowadziłem migrację rozwiązania, które obecnie jest ukierunkowane na .NET 4.0 w VS2010 na VS2012, a teraz chciałbym ponownie skierować go na .Net 4.5

Nie jestem pewien co do pakietów NuGet. Na przykład EF5, który zaktualizowałem z EF4 w VS2010, okazuje się faktycznie EF 4.4, jak widać tutaj:

    <Reference Include="EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\packages\EntityFramework.5.0.0\lib\net40\EntityFramework.dll</HintPath>
    </Reference>

Widzę również następujące elementy w pliku package.config dla projektu:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="EntityFramework" version="5.0.0" targetFramework="net40" />
</packages>

Więc moje pytanie brzmi:

Jaka jest najlepsza praktyka, aby ponownie skierować wszystkie pakiety NuGet, które są obecnie ustawione na .NET 4.0 na .NET 4.5?

Ivan Zlatev
źródło

Odpowiedzi:

266

NuGet 2.1 oferuje funkcję, która sprawia, że ​​jest to o wiele prostsze: wystarczy update-package -reinstall -ignoreDependenciesz poziomu konsoli Menedżera pakietów.

NuGet 2.0 nie radzi sobie zbyt dobrze z ukierunkowaniem aplikacji. Aby zmienić docelowe struktury pakietów, musisz odinstalować i ponownie zainstalować pakiety (zwracając uwagę na zainstalowane pakiety, aby móc ponownie zainstalować każdy z nich).

Powodem, dla którego pakiety muszą zostać odinstalowane i ponownie zainstalowane, są:

  • Podczas instalowania pakietu określamy docelową strukturę projektu
  • Następnie dopasowujemy to do zawartości pakietu, znajdując odpowiedni folder \ lib \ (i folder \ content \)
  • Odwołania do zestawu są dodawane ze ścieżkami wskazującymi, które wskazują folder \ lib \ pakietu, z odpowiednim podfolderem (na przykład \ lib \ net40)
  • Pliki zawartości są kopiowane z folderu packages \ content \, z odpowiednim podfolderem (na przykład \ content \ net40)
  • Rejestrujemy element docelowy używany do instalacji pakietu w pliku packages.config
  • Po zmianie struktury docelowej projektu ścieżki wskazówek nadal wskazują net40
  • Podczas odinstalowywania pakietów sprawdzamy element docelowy, który został zapisany w pakietach.config, aby zobaczyć, jakie biblioteki / treść docelowego środowiska do usunięcia z projektu
  • Podczas ponownej instalacji pakietu wykrywamy zaktualizowaną platformę docelową i odwołujemy się / kopiujemy odpowiednie biblioteki lib / /
Jeff Handley
źródło
Używając VS 2012 z projektem ASP.NET MVC 4 i po ponownym ukierunkowaniu .NET Framework z 4.0 na 4.5, wykonałem update-package -reinstallw konsoli Menedżera pakietów. Wszystkie pakiety zaczęły być odinstalowywane i aktualizowane, a nagle system Windows 8 uruchomił się ponownie, a gdy wrócił, powiedział: „Wystąpił problem z komputerem i uruchomiono go ponownie. Czy chcesz wysłać informacje do firmy Microsoft?” :( Przerażenie ... Nawiasem mówiąc, to jest wersja NuGet, którą właśnie zainstalowałem: 2.2.40116.9051Otworzyłem problem tutaj: nuget.codeplex.com/workitem/3049
Leniel Maccaferri
12
opcje -reinstall nigdy dla mnie nie działały. Usuwa w niewłaściwej kolejności i błędy „nie można usunąć X, ponieważ Y zależy od niego”, lub czasami po prostu nie czyta pakietów. Ostatnim razem, gdy go wypróbowałem, usunąłem EntityFramework, a następnie nigdy go nie dodałem.
CodingWithSpike 16.04.13
4
pakiet aktualizacji-reinstall nie był dla mnie rozwiązaniem. To również zaktualizowane wiele pakietów, zamiast zostawiać je w wersji używamy i nie testowanych przeciw. Na przykład Ninject został przeniesiony do wersji 3, co jest przełomową zmianą wersji.
Steve Owen,
13
Nawet nie próbuj ponownie instalować strony aktualizacji. To działało na takim bałaganie, gdy działało na mojej lokalnej maszynie, że musiałem powstrzymać menedżera pakietów NuGet od dalszego działania. Z jakiegoś powodu usunąłem moją wersję jQuery 1.10 i zastąpiłem ją 1.4.4. Po prostu zrób to ręcznie i oszczędzaj sobie kłopotów.
JustinMichaels,
2
Zgodziłem się z tym bałaganem, a to nawet dwa lata po tym poście. Znaleziono niższe wersje niektórych modeli użytkowych i zepsuło wiele odnośników. Było to po prawie dwóch godzinach aktualizacji (na wysokiej klasy stacji roboczej z początku 2014 roku). 20 projektów w rozwiązaniu.
Arve Systad
42

Dla tych, którzy mieli problemy z update-package -reinstall <packagename>poleceniem, rozważ uruchomienie go z -ignoreDependenciesflagą:

update-package -reinstall <packagename> -ignoreDependencies

Ta flaga pozostawi twoje zależności pakietu w spokoju, w przeciwnym razie mogą zostać zaktualizowane, nawet jeśli pakiet, którego pierwotnie chciałeś ponownie zainstalować, nadal zachowuje swoją wersję.

Więcej informacji tutaj .

vpalmu
źródło
Dzięki, to naprawdę oszczędza wiele kłopotów. Obserwowanie, jak Nuget próbuje ponownie zainstalować 10 lub więcej zależności, które ma tendencję do tworzenia EnterpriseLibrary w ponad 30 projektach, zmierza w kierunku dnia pracy. To sprowadza się do minut.
David Keaveny,
Jak wspomnieli inni, bardzo prawdopodobne, że wszystko zepsuje.
Gleno,
9
Możesz to zautomatyzować dla całego rozwiązania, zmieniając go tylko nieznacznie, gdy działa pod konsolą Menedżera pakietów:get-package | % { update-package $_.Id -reinstall -ProjectName $_.ProjectName -ignoreDependencies }
Kaleb Pederson
2
@KalebPederson Z mojego doświadczenia wynika, że ​​polecenie działa w szerokim zakresie?
1
@ BjörnAliGöransson - Przepraszam, jeśli nie byłem wystarczająco jasny. Odpowiedź zapewnia sposób na aktualizację jednego pakietu w całym rozwiązaniu. Mój skrypt przejdzie przez każdy pakiet NuGet w rozwiązaniu i przekieruje go na inne rozwiązanie. Odpowiedź jest idealna dla pojedynczego projektu, ale skrypt, który podałem, może być lepszy, jeśli masz wiele pakietów, które wymagają ponownej wyceny.
Kaleb Pederson
22

Po bezskutecznym wypróbowaniu zaakceptowanej odpowiedzi chciałbym zasugerować mniej ryzykowne polecenie:

Update-Package <PackageName> -ProjectName <ProjectName> -Reinstall -IgnoreDependencies

Aby uzyskać więcej informacji: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html

Bo Sunesen
źródło
1
Zgodnie z dołączoną dokumentacją -reinstallzainstaluje tylko tę samą wersję, więc nie widzę żadnych korzyści z używania -safe. Czy coś brakuje?
Kaleb Pederson
4

Podczas próby ponownej instalacji pakietów w całym rozwiązaniu napotkałem błąd zależności (pomimo użycia -ignoreDependenciesflagi) i wszystkie pliki packages.config dla każdego projektu zostały usunięte. W VS2013 wygląda na to, że packages.config nie dostać zaczerwienioną na dysk i ponownie dodany aż wszystkie zmodernizowane Zależności / referencje są ponownie przypisane do projektu.

W moim przypadku zadziałało uaktualnienie każdego projektu pojedynczo przez dodanie nazwy -ProjectName projektu do update-packagepolecenia. W tym przypadku pakiety.config jest aktualizowany podczas każdego projektu.

Może nie być praktyczny w przypadku bardzo dużych rozwiązań, ale rozsądnym kompromisem wydaje się nadal korzystanie z automatycznej aktualizacji dla jak największej liczby projektów i izolowanie problematycznych bez usuwania wszystkich pakietów package.config w rozwiązaniu po awarii.

Craigology
źródło
3
Natrafiłem na ten sam problem. UpdatePackage -Reinstallusunął plik package.config i odwołania do projektów dla kilku projektów (w szczególności tych, w których wygenerowano fałszywe zespoły). Obejrzeliśmy to, cofając wszystkie zmiany w spieprzonym projekcie i uruchamiając:Update-Package -reinstall -ProjectName "PROJECTNAME" -IgnoreDependencies
MSC
1

W programie Visual Studio dla komputerów Mac 2019 kliknięcie prawym przyciskiem myszy folderu Pakiety pokazuje w menu opcję „Retarget”. Rozwiązało to problem z retargetowaniem wszystkich pakietów w projekcie, które wymagały retargetowania. Wygląda na to, że nie było Menedżera pakietów NuGet w menu Narzędzia w Visual Studio dla komputerów Mac (przynajmniej mój), więc nie mogłem uruchomić konsoli Menedżera pakietów.

Opcja menu Retarget w menu Pakiety prawym przyciskiem myszy menu

Prabu Arumugam
źródło