Udostępnij za pośrednictwem

Informacje o wersji narzędzia NuGet 2.7

  • Artykuł

NuGet 2.6.1 for WebMatrix Release Notes | NuGet 2.7.1 — informacje o wersji

NuGet 2.7 został wydany 22 sierpnia 2013 r.

Podziękowania

Chcielibyśmy podziękować następującym zewnętrznym współautorom za znaczący wkład w pakiet NuGet 2.7:

  1. [Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
    • Pokaż adres URL licencji podczas wyświetlania listy pakietów i szczegółowości jest szczegółowy.
  2. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • [#1956](http://nuget.codeplex.com/workitem/1956) - Dodaj atrybut developmentDependency do packages.config i użyj go w pakiecie polecenia, aby uwzględnić tylko pakiety środowiska uruchomieniowego
  3. [Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
    • Unikaj duplikowania klucza Właściwości w nuget.exe pack polecenia.
  4. [Ben Phegan](http://www.codeplex.com/site/users/view/benphegan) (@BenPhegan)
    • [#2610](http://nuget.codeplex.com/workitem/2610) - Zwiększ rozmiar pamięci podręcznej maszyny do 200.
  5. [Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
    • [#3217](http://nuget.codeplex.com/workitem/3217) - Napraw okno dialogowe NuGet z wyświetlonymi aktualizacjami na niewłaściwej karcie
    • Poprawka elementu Project.TargetFramework może mieć wartość null w programie ProjectManager
    • [#3248](http://nuget.codeplex.com/workitem/3248) - Poprawka funkcji FindPackageRepository FindPackage/FindPackagesById zakończy się niepowodzeniem w przypadku nieistniejącego identyfikatora packageId
  6. [Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
    • [#3234](http://nuget.codeplex.com/workitem/3234) - Włączanie obsługi projektu Koczownicy
  7. [Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
    • [#3252](http://nuget.codeplex.com/workitem/3252) - Poprawka polecenia wypychania kończy się niepowodzeniem z kodem zakończenia 0, gdy plik nie istnieje.
  8. [Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
    • [#3226](http://nuget.codeplex.com/workitem/3226) - Napraw usterkę za pomocą polecenia Add-BindingRedirect, gdy projekt odwołuje się do projektu bazy danych.
  9. [Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
    • [#2891](http://nuget.codeplex.com/workitem/2891) - Naprawiono usterkę dotyczącą analizowania symbolu wieloznacznych nuget.pack w atrybucie "exclude" niepoprawnie.
  10. [Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
    • [#3307](http://nuget.codeplex.com/workitem/3307) - Poprawka usterki NuGet.targets nie przekazuje $(Platform) do nuget.exe podczas przywracania pakietów.
  11. [Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
    • [#3294](http://nuget.codeplex.com/workitem/3294) - Naprawiono usterkę w poleceniu pakietu nuget.exe, które umożliwiałoby dodawanie plików o tej samej nazwie, ale różne wielkości liter, powodując w końcu wyjątek "Element już istnieje".
  12. [Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
    • [#2990](http://nuget.codeplex.com/workitem/2990) - Dodaj właściwość Version do klasy NetPortableProfile.
  13. [David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
    • [#3460](https://nuget.codeplex.com/workitem/3460) - Naprawa usterki NullReferenceException, jeśli requireApiKey = true, ale nagłówek X-NUGET-APIKEY nie jest obecny
  14. [Michael Friis](https://www.codeplex.com/site/users/view/friism) (@friism)
    • [#3278](https://nuget.codeplex.com/workitem/3278) — Naprawia plik obiektów docelowych NuGet.Build w taki sposób, aby działał prawidłowo w pliku MonoDevelop
  15. [Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
    • Zwiększanie wydajności poleceń przywracania przez zwiększenie równoległego przetwarzania

Istotne funkcje w wersji

NuGet 2.7 wprowadza nowe podejście do przywracania pakietów, a także pozwala przezwyciężyć poważne przeszkody: zgoda na przywracanie pakietów jest teraz domyślnie włączona! Połączenie nowego podejścia i niejawnej zgody znacznie uprości scenariusze przywracania pakietów.

W przypadku pakietów NuGet w wersji 2.0, 2.1, 2.2, 2.5 i 2.6 użytkownicy musieli jawnie zezwolić nuGet na pobieranie brakujących pakietów podczas kompilacji. Jeśli ta zgoda nie została jawnie udzielona, wówczas rozwiązania, które włączyły przywracanie pakietów, nie będą kompilowane, dopóki użytkownik nie udzielił zgody.

Począwszy od pakietu NuGet 2.7, zgoda na przywracanie pakietów jest domyślnie włączona, umożliwiając użytkownikom jawne rezygnację z przywracania pakietu w razie potrzeby przy użyciu pola wyboru w ustawieniach nuGet w programie Visual Studio. Ta zmiana w przypadku niejawnej zgody wpływa na pakiet NuGet w następujących środowiskach:

  • Visual Studio 2013 Preview
  • Visual Studio 2012
  • Visual Studio 2010
  • nuget.exe narzędzie wiersza polecenia

Automatyczne przywracanie pakietów w programie Visual Studio

Począwszy od nuGet 2.7, NuGet automatycznie pobierze brakujące pakiety podczas kompilacji w programie Visual Studio, nawet jeśli przywracanie pakietów nie zostało jawnie włączone dla rozwiązania. To automatyczne przywracanie pakietów odbywa się w programie Visual Studio podczas tworzenia projektu lub rozwiązania, ale przed wywołaniem programu MSBuild. Daje to kilka znaczących korzyści:

  1. Nie trzeba już używać gestu "Włącz przywracanie pakietów NuGet" w rozwiązaniu
  2. Projekty nie muszą być modyfikowane, a pakiet NuGet nie wprowadza zmian w projekcie, aby upewnić się, że przywracanie pakietów jest włączone
  3. Wszystkie pakiety NuGet, w tym te, które obejmowały import MSBuild dla plików props/targets, zostaną przywrócone przed wywołaniem programu MSBuild, upewniając się, że te rekwizyty/obiekty docelowe są prawidłowo rozpoznawane podczas kompilacji

Aby można było używać automatycznego przywracania pakietów w programie Visual Studio, wystarczy wykonać jedną akcję (w)działaniu:

  1. Nie ewidencjonuj w packages folderze

Istnieje kilka sposobów pomijania packages folderu z kontroli źródła. Aby uzyskać więcej informacji, zobacz temat Pakiety i kontrola źródła.

Chociaż wszyscy użytkownicy są niejawnie wyrażani na zgodę na automatyczne przywracanie pakietów, możesz łatwo zrezygnować z ustawień Menedżer pakietów w programie Visual Studio.

Package Manager Settings

Uproszczone przywracanie pakietów z wiersza polecenia

NuGet 2.7 wprowadza nową funkcję dla nuget.exe: nuget.exe restore

To nowe polecenie Przywracania umożliwia łatwe przywracanie wszystkich pakietów dla rozwiązania za pomocą jednego polecenia, akceptując plik lub folder rozwiązania jako argument. Ponadto argument ten jest dorozumiany, gdy w bieżącym folderze znajduje się tylko jedno rozwiązanie. Oznacza to, że wszystkie następujące elementy działają z folderu zawierającego jeden plik rozwiązania (MySolution.sln):

  1. nuget.exe przywracania MySolution.sln
  2. nuget.exe przywracanie .
  3. przywracanie nuget.exe

Polecenie Przywróć otworzy plik rozwiązania i znajdzie wszystkie projekty w rozwiązaniu. W tym miejscu znajdzie packages.config pliki dla każdego z projektów i przywróci wszystkie znalezione pakiety. Przywraca również pakiety na poziomie rozwiązania znalezione w .nuget\packages.config pliku. Więcej informacji na temat nowego polecenia Przywracania można znaleźć w dokumentacji wiersza polecenia.

Przepływ pracy przywracania nowego pakietu

Cieszymy się z tych zmian w funkcji przywracania pakietów, ponieważ wprowadza on nowy przepływ pracy. Jeśli chcesz pominąć pakiety z kontroli źródła, po prostu nie zatwierdzaj packages folderu. Użytkownicy programu Visual Studio, którzy otwierają i kompilują rozwiązanie, zobaczą pakiety automatycznie przywrócone. W przypadku kompilacji wiersza polecenia po prostu wywołaj nuget.exe restore polecenie przed wywołaniem msbuildmetody . Nie musisz już pamiętać o użyciu gestu "Włącz przywracanie pakietów NuGet" w rozwiązaniu i nie będziemy już musieli modyfikować projektów w celu zmiany kompilacji. Daje to również znacznie ulepszone środowisko dla pakietów, które obejmują import MSBuild, zwłaszcza w przypadku importów dodanych za pośrednictwem najnowszej funkcji NuGet do automatycznego importowania plików props/targets z folderu \build.

Oprócz pracy, którą wykonaliśmy, współpracujemy również z niektórymi ważnymi partnerami, aby zaokrąglić to nowe podejście. Nie mamy jeszcze konkretnych harmonogramów dla żadnego z tych elementów, ale każdy partner jest tak podekscytowany, jak o nowym podejściu.

  • Usługa Team Foundation — pracują nad integracją wywołania z nuget.exe restore domyślnymi scenariuszami kompilacji.
  • Witryny internetowe platformy Windows Azure — działają one tak, aby umożliwić wypychanie projektu na platformę Azure i wywołanie nuget.exe restore jej przed skompilowania witryny internetowej.
  • TeamCity — aktualizują wtyczkę Instalatora NuGet dla usługi TeamCity 8.x
  • AppHarbor — pracują, aby umożliwić wypchnięcie repozytorium do aplikacji AppHarbor i wywołanie nuget.exe restore go przed kompilacją rozwiązania.

W przypadku każdego z powyższych partnerów będą używać własnej kopii nuget.exe i nie trzeba nosić nuget.exe w rozwiązaniu.

Znane problemy

Wystąpiły dwa znane problemy z przywracaniem nuget.exe z początkową wersją 2.7, ale zostały one rozwiązane w dniu 9.6.2013 r. z aktualizacją pakietu NuGet.CommandLine. Ta aktualizacja jest również dostępna w witrynie [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605) CodePlex. Uruchomienie nuget.exe update -self zostanie zaktualizowane do najnowszej wersji.

Naprawiono:

  1. [New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
  2. [New package restore doesn't work with Wix projects](https://nuget.codeplex.com/workitem/3598)

Istnieje również znany problem z nowym przepływem pracy przywracania pakietu, w którym [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625). Ten problem został rozwiązany w programie NuGet 2.7.1.

Błędy kompilacji/ostrzeżenia dotyczące ponownego pobierania i uaktualniania projektu

Wiele razy po ponownym uruchomieniu lub uaktualnieniu projektu okaże się, że niektóre pakiety NuGet nie działają prawidłowo. Niestety, nie ma żadnych wskazówek na ten temat, a następnie nie ma żadnych wskazówek, jak go rozwiązać. W wersji NuGet 2.7 używamy teraz niektórych zdarzeń programu Visual Studio do rozpoznawania, gdy projekt został skierowany lub uaktualniony w sposób, który ma wpływ na zainstalowane pakiety NuGet.

Jeśli wykryjemy, że na którekolwiek z Twoich pakietów miało wpływ ponowne pobieranie lub uaktualnianie, wygenerujemy natychmiastowe błędy kompilacji, aby poinformować Cię o tym. Oprócz natychmiastowego błędu kompilacji utrwaliśmy również flagę requireReinstallation="true" w packages.config pliku dla wszystkich pakietów, których dotyczyła retargeting, a każda kolejna kompilacja w programie Visual Studio będzie zgłaszać ostrzeżenia kompilacji dla tych pakietów.

Mimo że program NuGet nie może podjąć automatycznych akcji w celu ponownej instalacji pakietów, mamy nadzieję, że to wskazanie i ostrzeżenie pomoże Ci odkryć, kiedy trzeba ponownie zainstalować pakiety. Pracujemy również nad dokumentacją wskazówek dotyczących ponownej instalacji pakietów, do której prowadzą te komunikaty o błędach.

Wartości domyślne konfiguracji narzędzia NuGet

Wiele firm korzysta wewnętrznie z pakietu NuGet, ale miało trudności z prowadzeniem deweloperów w celu korzystania z wewnętrznych źródeł pakietów zamiast nuget.org. NuGet 2.7 wprowadza funkcję Defaults konfiguracji, która umożliwia określenie domyślnych ustawień dla całego komputera dla:

  1. Włączone źródła pakietów
  2. Zarejestrowane, ale wyłączone źródła pakietów
  3. Domyślne źródło wypychania nuget.exe

Każdy z tych elementów można teraz skonfigurować w pliku znajdującym się w %ProgramData%\NuGet\NuGetDefaults.Configlokalizacji . Jeśli ten plik konfiguracji określa źródła pakietów, domyślne źródło pakietu nuget.org nie zostanie zarejestrowane automatycznie, a te w pliku NuGetDefaults.Config zostaną zarejestrowane.

Chociaż nie jest to wymagane do korzystania z tej funkcji, oczekujemy, że firmy będą wdrażać NuGetDefaults.Config pliki przy użyciu zasad grupy.

Należy pamiętać, że ta funkcja nigdy nie spowoduje usunięcia źródła pakietu z ustawień nuGet dewelopera. Oznacza to, że jeśli deweloper użył już pakietu NuGet i w związku z tym ma zarejestrowane źródło pakietu nuget.org, nie zostanie on usunięty po utworzeniu NuGetDefaults.Config pliku.

Aby uzyskać więcej informacji na temat tej funkcji, zobacz Ustawienia domyślne konfiguracji pakietu NuGet.

Zmiana nazwy domyślnego źródła pakietu

Pakiet NuGet zawsze zarejestrował domyślne źródło pakietu o nazwie "Oficjalne źródło pakietu NuGet", które wskazuje na nuget.org. Ta nazwa była szczegółowa, a także nie określiła, gdzie rzeczywiście wskazuje. Aby rozwiązać te dwa problemy, zmieniliśmy nazwę tego źródła pakietu na "nuget.org" w interfejsie użytkownika. Adres URL źródła pakietu został również zmieniony tak, aby zawierał prefiks "www.". Po użyciu pakietu NuGet 2.7 istniejący "oficjalne źródło pakietu NuGet" zostanie automatycznie zaktualizowany do "nuget.org" jako nazwy i "https://www.nuget.org/api/v2/" jako adresu URL.

Usprawnienia wydajności

Wprowadziliśmy pewną poprawę wydajności w wersji 2.7, co zapewni mniejsze zużycie pamięci, mniejsze użycie dysku i szybszą instalację pakietu. Wprowadziliśmy również inteligentniejsze zapytania do źródeł danych opartych na protokole OData, co zmniejszy ogólny ładunek.

Nowe interfejsy API rozszerzalności

Dodaliśmy nowe interfejsy API do naszych usług rozszerzalności, aby wypełnić lukę brakujących funkcji w poprzednich wersjach.

IVsPackageInstallerServices

// Checks if a NuGet package with the specified Id and version is installed in the specified project.
bool IsPackageInstalledEx(Project project, string id, string versionString);

// Get the list of NuGet packages installed in the specified project.
IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);

IVsPackageInstaller

// Installs one or more packages that exist on disk in a folder defined in the registry.
void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

// Installs one or more packages that are embedded in a Visual Studio Extension Package.
void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

Zależności tylko do programowania

Ta funkcja została udostępniona przez Adama Ralpha i umożliwia autorom pakietów deklarowanie zależności, które były używane tylko w czasie programowania i nie wymagają zależności pakietów. Dodanie atrybutu developmentDependency="true" do pakietu w packages.confignuget.exe pack programie nie będzie już uwzględniać tego pakietu jako zależności.

Usunięto obsługę programu Visual Studio 2010 Express for Windows Telefon

Nowy model przywracania pakietów w wersji 2.7 jest implementowany przez nowy pakiet VSPackage, który różni się od głównego pakietu VSPackage NuGet. Ze względu na problem techniczny ten nowy pakiet VSPackage nie działa poprawnie w jednostce SKU programu Visual Studio 2010 Express for Windows Telefon, ponieważ współużytkujemy tę samą bazę kodu z innymi obsługiwanymi jednostkami SKU programu Visual Studio. W związku z tym, począwszy od nuGet 2.7, usuwamy obsługę programu Visual Studio 2010 Express for Windows Telefon z opublikowanego rozszerzenia. Obsługa programu Visual Studio 2010 Express for Web jest nadal dostępna w rozszerzeniu podstawowym opublikowanym w galerii rozszerzeń programu Visual Studio.

Ponieważ nie wiemy, ilu deweloperów nadal używa pakietu NuGet w tej wersji/edycji programu Visual Studio, publikujemy oddzielne rozszerzenie programu Visual Studio specjalnie dla tych użytkowników i publikujemy je w programie CodePlex (zamiast w galerii rozszerzeń programu Visual Studio). Nie planujemy nadal utrzymywać tego rozszerzenia, ale jeśli to wpłynie na Ciebie, daj nam znać, zgłaszając problem w pliku CodePlex.

Aby pobrać Menedżer pakietów NuGet (dla programu Visual Studio 2010 Express for Windows Telefon), odwiedź [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605) stronę.

Poprawki błędów

Oprócz tych funkcji ta wersja pakietu NuGet zawiera również wiele innych poprawek błędów. W wydaniu rozwiązano łącznie 97 problemów. Aby uzyskać pełną listę elementów roboczych stałych w programie NuGet 2.7, wyświetl element [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all).