Informacje o wersji narzędzia NuGet 2.5

Informacje o wersji | NuGet 2.2.1 NuGet 2.6

NuGet 2.5 został wydany 25 kwietnia 2013 r. Ta wersja była tak duża, czuliśmy się zmuszeni pominąć wersje 2.3 i 2.4! Do tej pory jest to największa wersja, którą mieliśmy dla nuGet, z ponad [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) w wydaniu.

Podziękowania

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

1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
   • [#2847](https://nuget.codeplex.com/workitem/2847) — Dodaj monoAndroid, MonoTouch i MonoMac do listy znanych identyfikatorów platform docelowych.
2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
   • [#2865](https://nuget.codeplex.com/workitem/2865) - Naprawianie NuGet.targets pisowni dla systemu operacyjnego z uwzględnieniem wielkości liter
3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
   • Utwórz rozwiązanie oparte na rozwiązaniu Mono.
4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
   • Naprawianie niepowodzeń testów jednostkowych na platformie Mono.
5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
   • [#2920](https://nuget.codeplex.com/workitem/2920) - nuget.exe pack polecenie nie propaguje właściwości do MSBuild
6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
   • [#1511](https://nuget.codeplex.com/workitem/1511) - Zmodyfikowany kod obsługi XML w celu zachowania formatowania.
7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
   • Dodano rozpoznane wyrazy do słownika niestandardowego, aby umożliwić build.cmd powodzenie.
8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
   • Napraw testy jednostkowe podczas uruchamiania w zlokalizowanym programie VS.
9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
   • Wyodrębniony interfejs z usługi PackageService
10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936) — Obsługa zależności projektu podczas pakowania
11. [Xavier Decoster](https://www.codeplex.com/site/users/view/XavierDecoster) (@XavierDecoster)
    • [#2991](https://nuget.codeplex.com/workitem/2991), [#3164](https://nuget.codeplex.com/workitem/3164) — obsługa hasła zwykłego tekstu podczas przechowywania poświadczeń źródłowych pakietu w plikach nuget.cofig
12. [James Manning](http://www.codeplex.com/site/users/view/jmanning) (@manningj)
    • [#3190](http://nuget.codeplex.com/workitem/3190), [#3191](https://nuget.codeplex.com/workitem/3191) — naprawianie opisu pomocy dotyczącej pobierania pakietu

Doceniamy również następujące osoby do znajdowania błędów w wersji Beta/RC NuGet 2.5, które zostały zatwierdzone i naprawione przed ostatecznym wydaniem:

1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
   • [#3200](https://nuget.codeplex.com/workitem/3200) — Narzędzie MSTest nie działa w przypadku najmocniejszych kompilacji NuGet 2.4 i 2.5

Istotne funkcje w wersji

Zezwalaj użytkownikom na zastępowanie plików zawartości, które już istnieją

Jedną z najbardziej żądanych funkcji wszech czasów była możliwość zastępowania plików zawartości, które już istnieją na dysku, jeśli są uwzględnione w pakiecie NuGet. Począwszy od nuGet 2.5, te konflikty są identyfikowane i są monitowane o zastąpienie plików, podczas gdy wcześniej te pliki były zawsze pomijane.

Polecenia "nuget.exe update" i "Install-Package" mają teraz nową opcję "-FileConflictAction", aby ustawić wartość domyślną dla scenariuszy wiersza polecenia.

Ustaw akcję domyślną, gdy plik z pakietu już istnieje w projekcie docelowym. Ustaw wartość "Zastąp", aby zawsze zastępować pliki. Ustaw wartość "Ignoruj", aby pominąć pliki. Jeśli nie zostanie określony, zostanie wyświetlony monit o podanie każdego pliku powodującego konflikt.

Automatyczne importowanie obiektów docelowych i plików props programu MSBuild

Nowy konwencjonalny folder został utworzony na najwyższym poziomie pakietu NuGet. Jako element równorzędny z \libelementami , \contenti \toolsmożna teraz dołączyć \build folder do pakietu. W tym folderze można umieścić dwa pliki ze stałymi nazwami {packageid}.targets lub {packageid}.props. Te dwa pliki mogą znajdować się bezpośrednio w build folderach specyficznych dla platformy lub w folderach, podobnie jak w przypadku innych folderów. Reguła wybierania najlepiej dopasowanego folderu struktury jest dokładnie taka sama jak w tych.

Gdy program NuGet instaluje pakiet z plikami \build, doda element MSBuild <Import> w pliku projektu wskazujący pliki .targets i .props . Plik .props jest dodawany u góry, natomiast .targets plik jest dodawany do dołu.

Określanie różnych odwołań na platformę przy użyciu <References/> elementu

Przed 2.5 w .nuspec pliku użytkownik może określić tylko pliki referencyjne, które mają zostać dodane dla wszystkich struktur. Teraz dzięki tej nowej funkcji w wersji 2.5 użytkownik może utworzyć <reference/> element dla każdej z obsługiwanych platform, na przykład:

<references>
    <group targetFramework="net45">
        <reference file="a.dll" />
    </group>
    <group targetFramework="netcore45">
        <reference file="b.dll" />
    </group>
    <group>
        <reference file="c.dll" />
    </group>
</references>

Oto przepływ dodawania odwołań do projektów w oparciu .nuspec o plik NuGet:

1. lib Znajdź folder odpowiedni dla platformy docelowej i pobierz listę zestawów z tego folderu
2. Oddzielnie znajdź grupę odwołań odpowiednią dla platformy docelowej i pobierz listę zestawów z tej grupy. Grupa referencyjna bez określonej platformy docelowej jest grupą rezerwową.
3. Znajdź przecięcie dwóch list i użyj go jako odwołań, aby dodać

Ta nowa funkcja umożliwi autorom pakietów używanie funkcji Odwołania do stosowania podzbiorów zestawów do różnych struktur, gdy w przeciwnym razie będą musieli przenosić zduplikowane zestawy w wielu lib folderach.

Uwaga: do korzystania z tej funkcji należy obecnie używać pakietu nuget.exe; Eksplorator pakietów NuGet jeszcze go nie obsługuje.

Przycisk Aktualizuj wszystko, aby zezwolić na aktualizowanie wszystkich pakietów jednocześnie

Wiele z was wie o poleceniu cmdlet programu PowerShell "Update-Package" w celu zaktualizowania wszystkich pakietów; teraz istnieje prosty sposób, aby to zrobić za pośrednictwem interfejsu użytkownika, jak również.

Aby wypróbować tę funkcję:

1. tworzenie nowej aplikacji platformy ASP.NET MVC
2. Uruchamianie okna dialogowego "Zarządzanie pakietami NuGet"
3. Wybierz pozycję "Aktualizacje"
4. Kliknij przycisk "Aktualizuj wszystko"

Ulepszona obsługa referencyjna projektu dla pakietu nuget.exe Pack

Teraz nuget.exe spakować procesy poleceń odwołujące się do projektów z następującymi regułami:

1. Jeśli przywoływany projekt ma odpowiedni .nuspec plik, np. istnieje plik o nazwie proj1.nuspec w tym samym folderze co proj1.csproj, ten projekt jest dodawany jako zależność do pakietu przy użyciu identyfikatora i wersji odczytanej .nuspec z pliku.
2. W przeciwnym razie pliki przywoływania projektu są umieszczane w pakiecie. Następnie projekty, do których odwołuje się ten projekt, będą przetwarzane przy użyciu reguł tych samych cyklicznie.
3. Dodawana jest cała biblioteka DLL, .pdbi .exe pliki.
4. Wszystkie inne pliki zawartości są dodawane.
5. Wszystkie zależności są scalane.

Dzięki temu projekt, do której odwołuje się odwołanie, może być traktowany jako zależność, jeśli istnieje .nuspec plik, w przeciwnym razie staje się częścią pakietu.

Więcej szczegółów można znaleźć tutaj: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Dodawanie właściwości "Minimalna wersja pakietu NuGet" do pakietów

Nowy atrybut metadanych o nazwie "minClientVersion" może teraz wskazywać minimalną wersję klienta NuGet wymaganą do korzystania z pakietu.

Ta funkcja pomaga autorowi pakietu określić, że pakiet będzie działał tylko po określonej wersji pakietu NuGet. W miarę dodawania nowych .nuspec funkcji po nuGet 2.5 pakiety będą mogły ubiegać się o minimalną wersję NuGet.

<metadata minClientVersion="2.6">

Jeśli użytkownik ma zainstalowany pakiet NuGet 2.5, a pakiet zostanie zidentyfikowany jako wymagający 2.6, zostaną podane użytkownikowi wskazówki wizualne wskazujące, że pakiet nie będzie można zainstalować. Użytkownik zostanie następnie z przewodnikiem, aby zaktualizować swoją wersję pakietu NuGet.

Poprawi to istniejące środowisko, w którym pakiety zaczynają się instalować, ale następnie kończy się niepowodzeniem wskazującym, że zidentyfikowano nierozpoznaną wersję schematu.

Zależności nie są już niepotrzebnie aktualizowane podczas instalacji pakietu

Przed nuGet 2.5, gdy pakiet został zainstalowany, który był zależny od pakietu już zainstalowanego w projekcie, zależność zostanie zaktualizowana w ramach nowej instalacji, nawet jeśli istniejąca wersja spełnia zależność.

Począwszy od pakietu NuGet 2.5, jeśli wersja zależności jest już spełniona, zależność nie zostanie zaktualizowana podczas innych instalacji pakietów.

Scenariusz:

1. Repozytorium źródłowe zawiera pakiet B z wersją 1.0.0 i 1.0.2. Zawiera również pakiet A, który ma zależność od B (>= 1.0.0).
2. Załóżmy, że bieżący projekt ma już zainstalowany pakiet B w wersji 1.0.0. Teraz chcesz zainstalować pakiet A.

W programie NuGet 2.2 i starszych:

• Podczas instalowania pakietu A pakiet NuGet automatycznie zaktualizuje usługę B do wersji 1.0.2, mimo że istniejąca wersja 1.0.0 spełnia już ograniczenie wersji zależności, czyli >= 1.0.0.

W systemach NuGet 2.5 i nowszych:

• Program NuGet nie zaktualizuje już usługi B, ponieważ wykryje, że istniejąca wersja 1.0.0 spełnia ograniczenie wersji zależności.

Aby uzyskać więcej informacji na temat tej zmiany, zapoznaj się ze szczegółowymi informacjami [work item](https://nuget.codeplex.com/workitem/1681) , a także powiązanymi elementami [discussion thread](https://nuget.codeplex.com/discussions/436712).

nuget.exe generuje żądania HTTP ze szczegółowością szczegółowości

Jeśli rozwiązujesz problemy nuget.exe lub po prostu zastanawiasz się, jakie żądania HTTP są wykonywane podczas operacji, przełącznik "-verbosity detailed" będzie teraz zwracać wszystkie żądania HTTP wykonane.

nuget.exe wypychanie obsługuje teraz źródła UNC i foldery

Przed nuGet 2.5, jeśli podjęto próbę uruchomienia wypychania "nuget.exe" do źródła pakietu na podstawie ścieżki UNC lub folderu lokalnego, wypychanie zakończy się niepowodzeniem. Po dodaniu niedawno dodanej funkcji konfiguracji hierarchicznej stało się ono powszechne, aby nuget.exe musiały być przeznaczone dla źródła UNC/folderu lub galerii NuGet opartej na protokole HTTP.

Począwszy od narzędzia NuGet 2.5, jeśli nuget.exe zidentyfikuje źródło UNC/folder, wykona kopię pliku do źródła.

Następujące polecenie będzie teraz działać:

nuget push -source \\mycompany\repo\ mypackage.1.0.0.nupkg

nuget.exe obsługuje jawnie określone pliki konfiguracji

nuget.exe polecenia, które uzyskują dostęp do konfiguracji (wszystkie z wyjątkiem "spec" i "pack") obsługują teraz nową opcję "-ConfigFile", która wymusza użycie określonego pliku konfiguracji zamiast domyślnego pliku konfiguracji w lokalizacji %AppData%\nuget\Nuget.Config.

Przykład:

nuget sources add -name test -source http://test -ConfigFile C:\test\.nuget\Nuget.Config

Obsługa projektów natywnych

W przypadku narzędzia NuGet 2.5 narzędzia NuGet są teraz dostępne dla projektów natywnych w programie Visual Studio. Oczekujemy, że większość pakietów natywnych będzie korzystać z powyższej funkcji importowania programu MSBuild przy użyciu narzędzia utworzonego przez projekt CoApp. Aby uzyskać więcej informacji, przeczytaj szczegółowe informacje o narzędziu w witrynie internetowej coapp.org.

Nazwa platformy docelowej "natywna" jest wprowadzana dla pakietów do dołączania plików do \build, \content i \tools, gdy pakiet jest zainstalowany w projekcie natywnym. Folder "lib" nie jest używany dla projektów natywnych.