Przeczytaj w języku angielskim

Udostępnij za pośrednictwem


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.

Hierarchiczny plik Nuget.Config

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:

Package sources from parent nuget config

NuGet.Config pliki są wyszukiwane w następującej kolejności:

  1. .nuget\Nuget.Config
  2. Cyklisywny przewodnik 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 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.

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

Obsługa bibliotek przenośnych

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.

Portable library creation dialog

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.

Portable library package layout

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.

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

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

Ulepszone wyszukiwanie w oknie dialogowym Menedżer 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 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.

Package manager dialog search

Wymuszanie aktualizacji pakietu

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.

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 pierwszą klasę interfejsu użytkownika konfiguracji.

Package manager configuration dialog

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