Informacje o wersji narzędzia NuGet 2.1
Informacje o wersji | narzędzia NuGet 2.0 NuGet 2.2
NuGet 2.1 został wydany 4 października 2012 r.
Pakiet NuGet 2.1 zapewnia większą elastyczność w kontrolowaniu ustawień NuGet poprzez cyklicznego przechodzenia w strukturę folderów wyszukując NuGet.Config
pliki, a następnie kompilując konfigurację z zestawu wszystkich znalezionych plików. Rozważmy na przykład scenariusz, w którym zespół ma wewnętrzne repozytorium pakietów dla kompilacji ciągłej integracji innych zależności wewnętrznych. Struktura folderów dla pojedynczego projektu może wyglądać następująco:
C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1
Ponadto jeśli przywracanie pakietów jest włączone dla rozwiązania, będzie również istnieć następujący folder:
C:\myteam\solution1\.nuget
Aby mieć wewnętrzne repozytorium pakietów zespołu dostępne dla wszystkich projektów, nad którymi pracuje zespół, a jednocześnie nie udostępniać go dla każdego projektu na maszynie, możemy utworzyć nowy plik Nuget.Config i umieścić go w folderze c:\myteam. Nie ma możliwości określonego folderu pakietów dla każdego projektu.
<configuration>
<packageSources>
<add key="Official project team source" value="http://teamserver/api/v2/" />
</packageSources>
<disabledPackageSources />
<activePackageSource>
<add key="Official project team source" value="http://teamserver/api/v2/" />
</activePackageSource>
</configuration>
Teraz możemy zobaczyć, że źródło zostało dodane, uruchamiając polecenie "nuget.exe sources" z dowolnego folderu pod c:\myteam, jak pokazano poniżej:
NuGet.Config
pliki są wyszukiwane w następującej kolejności:
.nuget\Nuget.Config
- Cyklisywny przewodnik z folderu projektu do katalogu głównego
- Globalny
Nuget.Config
(%appdata%\NuGet\Nuget.Config
)
Konfiguracje są stosowane w odwrotnej kolejności, co oznacza, że na podstawie powyższej kolejności globalne nuget.Config zostaną zastosowane najpierw, a następnie odnalezione pliki Nuget.Config z katalogu głównego do folderu projektu, a następnie .nuget\Nuget.Config
. Jest to szczególnie ważne, jeśli używasz <clear/>
elementu do usunięcia zestawu elementów z konfiguracji.
W przeszłości nuGet zarządzał pakietami rozwiązania ze znanego folderu "packages" znajdującego się pod folderem głównym rozwiązania. W przypadku zespołów programistycznych z wieloma różnymi rozwiązaniami, które mają zainstalowane pakiety NuGet, może to spowodować zainstalowanie tego samego pakietu w wielu różnych miejscach w systemie plików.
Pakiet NuGet 2.1 zapewnia bardziej szczegółową kontrolę nad lokalizacją folderu packages za pośrednictwem repositoryPath
elementu w NuGet.Config
pliku. Opierając się na poprzednim przykładzie obsługi hierarchicznej biblioteki Nuget.Config, załóżmy, że chcemy mieć wszystkie projekty w folderze C:\myteam\ współużytkować ten sam folder packages. Aby to zrobić, wystarczy dodać następujący wpis do c:\myteam\Nuget.Config
.
<configuration>
<config>
<add key="repositoryPath" value="C:\myteam\teampackages" />
</config>
...
</configuration>
W tym przykładzie udostępniony plik określa folder pakietów udostępnionych Nuget.Config
dla każdego projektu, który jest tworzony pod C:\myteam, niezależnie od głębokości. Należy pamiętać, że jeśli masz istniejący folder packages pod katalogiem głównym rozwiązania, musisz go usunąć, zanim pakiet NuGet zostanie umieszczany w nowej lokalizacji.
Biblioteki przenośne to funkcja wprowadzona po raz pierwszy z platformą .NET 4, która umożliwia tworzenie zestawów, które mogą działać bez modyfikacji na różnych platformach Firmy Microsoft, od wersji platformy the.NET Platformy do programu Silverlight do systemu Windows Telefon, a nawet konsoli Xbox 360 (choć w tej chwili NuGet nie obsługuje docelowej biblioteki przenośnej Xbox). Rozszerzając konwencje pakietów dla wersji i profilów platformy, NuGet 2.1 obsługuje teraz biblioteki przenośne, umożliwiając tworzenie pakietów, które mają złożone struktury i foldery docelowe lib
profilów.
Rozważmy na przykład następujące platformy docelowe biblioteki klas przenośnych.
Po skompilowaniu biblioteki i uruchomieniu polecenia nuget.exe pack MyPortableProject.csproj
można zobaczyć nową strukturę folderów pakietów biblioteki przenośnej, sprawdzając zawartość wygenerowanego pakietu NuGet.
Jak widać, konwencja nazwy folderu biblioteki przenośnej jest zgodna ze wzorcem "portable-{framework 1}+{framework n}", w którym identyfikatory struktury są zgodne z istniejącą konwencją nazwy i wersji struktury. Jeden wyjątek od konwencji nazw i wersji znajduje się w identyfikatorze struktury używanym dla systemu Windows Telefon. Ten moniker powinien używać nazwy struktury "wp" (wp7, wp71 lub wp8). Na przykład użycie polecenia "silverlight-wp7" spowoduje wystąpienie błędu.
Podczas instalowania pakietu utworzonego na podstawie tej struktury folderów program NuGet może teraz zastosować reguły struktury i profilu do wielu obiektów docelowych, jak określono w nazwie folderu. Za regułami dopasowywania NuGet jest zasada, że "bardziej szczegółowe" cele będą miały pierwszeństwo przed "mniej specyficznymi" celami. Oznacza to, że monikers przeznaczone dla określonej platformy zawsze będą preferowane w przypadku przenośnych, jeśli są one zgodne z projektem. Ponadto jeśli wiele przenośnych obiektów docelowych jest zgodnych z projektem, nuGet preferuje ten, w którym obsługiwany zestaw platform jest "najbliżej" projektu odwołującego się do pakietu.
Oprócz dodawania obsługi docelowych projektów bibliotek przenośnych NuGet 2.1 udostępnia nowe monikers struktury zarówno dla projektów Sklepu Windows 8, jak i Windows Telefon 8, a także kilka nowych ogólnych monikers dla Sklepu Windows i projektów systemu Windows Telefon, które będą łatwiejsze do zarządzania w przyszłych wersjach odpowiednich platform.
W przypadku aplikacji ze Sklepu Windows 8 identyfikatory wyglądają następująco:
NuGet 2.0 i starsze wersje | NuGet 2.1 |
---|---|
winRT45, . NETCore45 | Windows, Windows8, win, win8 |
W przypadku projektów Telefon systemu Windows identyfikatory wyglądają następująco:
system operacyjny Telefon | NuGet 2.0 i starsze wersje | NuGet 2.1 |
---|---|---|
Windows Telefon 7 | silverlight3-wp | wp, wp7, Windows Telefon, Windows Telefon 7 |
Windows Telefon 7.5 (Mango) | silverlight4-wp71 | wp71, Windows Telefon 71 |
Windows Phone 8 | (nieobsługiwane) | wp8, Windows Telefon 8 |
We wszystkich powyższych zmianach stare nazwy struktur będą nadal w pełni obsługiwane przez pakiet NuGet 2.1. W przyszłości nowe nazwy powinny być używane, ponieważ będą one bardziej stabilne w przyszłych wersjach odpowiednich platform. Nowe nazwy *nie* będą obsługiwane w wersjach nuGet wcześniejszych niż 2.1, więc należy odpowiednio zaplanować, kiedy zmienić.
W ciągu ostatnich kilku iteracji wprowadzono zmiany w galerii NuGet, które znacznie poprawiły szybkość i znaczenie wyszukiwania pakietów. Jednak te ulepszenia były ograniczone do witryny sieci Web nuget.org. Pakiet NuGet 2.1 udostępnia ulepszone środowisko wyszukiwania za pośrednictwem okna dialogowego Menedżera pakietów NuGet. Załóżmy na przykład, że chcesz znaleźć pakiet windows Azure Buforowanie Preview. Rozsądne zapytanie wyszukiwania dla tego pakietu może być "Azure Cache". W poprzednich wersjach okna dialogowego Menedżera pakietów żądany pakiet nie zostałby nawet wyświetlony na pierwszej stronie wyników. Jednak w programie NuGet 2.1 żądany pakiet jest teraz wyświetlany w górnej części wyników wyszukiwania.
Przed nuGet 2.1 NuGet pomija aktualizowanie pakietu, gdy nie było dużego numeru wersji. W ten sposób wprowadzono tarcie w niektórych scenariuszach — szczególnie w przypadku scenariuszy kompilacji lub ciągłej integracji, w których zespół nie chciał zwiększać numeru wersji pakietu z każdą kompilacją. Żądanym zachowaniem było wymusić aktualizację niezależnie od tego. Program NuGet 2.1 rozwiązuje ten problem z flagą "zainstaluj ponownie". Na przykład poprzednie wersje pakietu NuGet spowodują wykonanie następującej próby zaktualizowania pakietu, który nie miał nowszej wersji pakietu:
PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.
Wraz z flagą ponownej instalacji pakiet zostanie zaktualizowany niezależnie od tego, czy istnieje nowsza wersja.
PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.
Innym scenariuszem, w którym flaga ponownej instalacji okazała się korzystna, jest ponowne ukierunkowanie platformy. Podczas zmiany struktury docelowej projektu (na przykład z platformy .NET 4 na .NET 4.5), update-package -Install może zaktualizować odwołania do odpowiednich zestawów dla wszystkich pakietów NuGet zainstalowanych w projekcie.
W poprzednich wersjach pakietu NuGet aktualizowanie źródła pakietu z poziomu okna dialogowego opcji programu Visual Studio wymaga usunięcia i ponownego dodania źródła pakietu. NuGet 2.1 ulepsza ten przepływ pracy, obsługując aktualizację jako pierwszą klasę interfejsu użytkownika konfiguracji.
NuGet 2.1 zawiera wiele poprawek błędów. Aby uzyskać pełną listę elementów roboczych stałych w programie NuGet 2.0, wyświetl element [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0)
.