Informacje o wersji narzędzia NuGet 2.1

Informacje o | Informacje o wersji narzędzia NuGet 2.2

NuGet 2.1 został wydany 4 października 2012 r.

Hierarchiczny plik NuGet.Config

Pakiet NuGet 2.1 zapewnia większą elastyczność w kontrolowaniu ustawień NuGet poprzez rekurencyjne przechodzenie w górę struktury folderów, wyszukując pliki NuGet.Config, a następnie tworząc konfigurację na podstawie wszystkich znalezionych plików. Rozważmy scenariusz, w którym zespół ma wewnętrzne repozytorium pakietów dla kompilacji w ramach 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:

1. .nuget\Nuget.Config
2. Rekurencyjne przechodzenie z folderu projektu do katalogu głównego
3. Globalny Nuget.Config (%appdata%\NuGet\Nuget.Config)

Konfiguracje są stosowane w odwrotnej kolejności, co oznacza, że na podstawie powyższej kolejności globalny Nuget.Config zostanie zastosowany najpierw, a następnie odnalezione pliki Nuget.Config, począwszy od 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.

Określanie lokalizacji folderu "packages"

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 z pakietami za pomocą elementu repositoryPath w pliku NuGet.Config. Opierając się na poprzednim przykładzie obsługi hierarchicznej pliku Nuget.Config, załóżmy, że chcemy, aby wszystkie projekty pod ścieżką C:\myteam\ dzieliły 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.

Obsługa bibliotek przenośnych

Biblioteki przenośne to funkcja po raz pierwszy wprowadzona 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 Framework do programu Silverlight do systemu Windows Phone, a nawet konsoli Xbox 360 (choć w tej chwili NuGet nie obsługuje docelowej biblioteki przenośnej Xbox). Rozszerzając konwencje dotyczące pakietów dla wersji i profilów platformy, NuGet 2.1 teraz obsługuje biblioteki przenośne, umożliwiając tworzenie pakietów, które mają złożone foldery docelowe dla struktur i profili lib.

Rozważmy na przykład następujące platformy docelowe biblioteki klas mobilnych.

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 Phone. 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 monikery przeznaczone dla określonej platformy zawsze będą preferowane nad przenośnymi, jeśli oba są 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.

Określanie docelowych projektów systemów Windows 8 i Windows Phone 8

Oprócz dodania wsparcia dla docelowych projektów bibliotek przenośnych, NuGet 2.1 udostępnia nowe nazwy systemowe zarówno dla projektów Windows 8 Store i Windows Phone 8, jak i niektórych nowych ogólnych oznaczeń dla projektów Sklepu Windows i Windows Phone, które będą łatwiejsze do zarządzania w przyszłych wersjach tych 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 systemu Windows Phone identyfikatory wyglądają następująco:

System operacyjny telefonu	NuGet 2.0 i starsze wersje	NuGet 2.1
Windows Phone 7	silverlight3-wp	wp, wp7, WindowsPhone, WindowsPhone7
Windows Phone 7.5 (Mango)	silverlight4-wp71	wp71, WindowsPhone71
Windows Phone 8	(nieobsługiwane)	wp8, WindowsPhone8

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ć.

Ulepszone wyszukiwanie w oknie dialogowym Menedżera pakietów

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 Caching 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.

Wymuszanie aktualizacji pakietu

Przed NuGet 2.1, NuGet pomijał aktualizowanie pakietu, kiedy nie było wyższej wersji. To wprowadziło tarcie w niektórych scenariuszach – szczególnie w przypadku scenariuszy kompilacji lub CI, gdzie 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 powodowały następujący rezultat przy próbie aktualizacji pakietu, który nie miał nowszej wersji.

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 okazuje się korzystna, jest ponowne ukierunkowanie frameworku. Podczas zmiany struktury docelowej projektu (na przykład z platformy .NET 4 na .NET 4.5), Update-Package -Reinstall może zaktualizować odwołania do odpowiednich zestawów dla wszystkich pakietów NuGet zainstalowanych w projekcie.

Edytowanie źródeł pakietów w programie Visual Studio

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 funkcję pierwszej klasy w interfejsie użytkownika konfiguracji.

Poprawki błędów

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).