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.
Chcielibyśmy podziękować następującym zewnętrznym współautorom za znaczący wkład w pakiet NuGet 2.5:
[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.
[Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte)
(@knocte)[#2865](https://nuget.codeplex.com/workitem/2865)
- NaprawianieNuGet.targets
pisowni dla systemu operacyjnego z uwzględnieniem wielkości liter
[David Fowler](https://www.codeplex.com/site/users/view/dfowler)
(@davidfowl)- Utwórz rozwiązanie oparte na rozwiązaniu Mono.
[Andrew Theken](https://www.codeplex.com/site/users/view/atheken)
(@atheken)- Naprawianie niepowodzeń testów jednostkowych na platformie Mono.
[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
[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.
[Adam Ralph](http://www.codeplex.com/site/users/view/adamralph)
(@adamralph)- Dodano rozpoznane wyrazy do słownika niestandardowego, aby umożliwić build.cmd powodzenie.
[Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
- Napraw testy jednostkowe podczas uruchamiania w zlokalizowanym programie VS.
[Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
- Wyodrębniony interfejs z usługi PackageService
[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
[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
[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:
[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
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.
Nowy konwencjonalny folder został utworzony na najwyższym poziomie pakietu NuGet. Jako element równorzędny z \lib
elementami , \content
i \tools
moż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.
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:
lib
Znajdź folder odpowiedni dla platformy docelowej i pobierz listę zestawów z tego folderu- 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ą.
- 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.
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ę:
- tworzenie nowej aplikacji platformy ASP.NET MVC
- Uruchamianie okna dialogowego "Zarządzanie pakietami NuGet"
- Wybierz pozycję "Aktualizacje"
- Kliknij przycisk "Aktualizuj wszystko"
Teraz nuget.exe spakować procesy poleceń odwołujące się do projektów z następującymi regułami:
- Jeśli przywoływany projekt ma odpowiedni
.nuspec
plik, np. istnieje plik o nazwieproj1.nuspec
w tym samym folderze coproj1.csproj
, ten projekt jest dodawany jako zależność do pakietu przy użyciu identyfikatora i wersji odczytanej.nuspec
z pliku. - 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.
- Dodawana jest cała biblioteka DLL,
.pdb
i.exe
pliki. - Wszystkie inne pliki zawartości są dodawane.
- 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)
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.
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:
- 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).
- 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)
.
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.
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 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
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.