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

stackoverflow.com/questions/6876732/…

— Ohad Schneider

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.

— Prabu Arumugam
źródło