Dela via

Viktig information om NuGet 2.7

Viktig information | Viktig information om NuGet 2.7.1

NuGet 2.7 släpptes den 22 augusti 2013.

Bekräftelser

Vi vill tacka följande externa deltagare för deras betydande bidrag till NuGet 2.7:

  1. [Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
    • Visa licens-URL när paketen listas och utförligheten är detaljerad.
  2. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • [#1956](http://nuget.codeplex.com/workitem/1956) – Lägg till attributet developmentDependency i packages.config och använd det i packkommandot för att endast inkludera körningspaket
  3. [Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
    • Undvik dubblettnyckeln för Egenskaper när du använder kommandot nuget.exe pack.
  4. [Ben Phegan](http://www.codeplex.com/site/users/view/benphegan) (@BenPhegan)
    • [#2610](http://nuget.codeplex.com/workitem/2610) – Öka storleken på datorns cacheminne till 200.
  5. [Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
    • [#3217](http://nuget.codeplex.com/workitem/3217) – Åtgärda NuGet-dialogrutan som visar uppdateringar på fel flik
    • Åtgärda Project.TargetFramework kan vara null i ProjectManager
    • [#3248](http://nuget.codeplex.com/workitem/3248) - Fix SharedPackageRepository FindPackage/FindPackagesById kommer att misslyckas för ett paket-ID som inte existerar
  6. [Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
    • [#3234](http://nuget.codeplex.com/workitem/3234) – Aktivera stöd för Nomad-projekt
  7. [Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
    • [#3252](http://nuget.codeplex.com/workitem/3252) – Det går inte att åtgärda push-kommandot med slutkod 0 när filen inte finns.
  8. [Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
    • [#3226](http://nuget.codeplex.com/workitem/3226) – Åtgärda bugg med kommandot Add-BindingRedirect när ett projekt refererar till ett databasprojekt.
  9. [Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
    • [#2891](http://nuget.codeplex.com/workitem/2891) – Åtgärda felet för nuget.pack-parsning av jokertecken i attributet "exclude" felaktigt.
  10. [Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
    • [#3307](http://nuget.codeplex.com/workitem/3307) - Korrigeringsfel NuGet.targets skickar inte $(Platform) till nuget.exe när paket återställs.
  11. [Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
    • [#3294](http://nuget.codeplex.com/workitem/3294) - Åtgärda fel i nuget.exe-paketkommando som skulle tillåta att filer med samma namn men ett annat hölje läggs till, vilket så småningom orsakar undantaget "Objektet finns redan".
  12. [Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
    • [#2990](http://nuget.codeplex.com/workitem/2990) – Lägg till egenskapen Version i klassen NetPortableProfile.
  13. [David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
    • [#3460](https://nuget.codeplex.com/workitem/3460) – Åtgärda felet NullReferenceException om requireApiKey = true, men rubriken X-NUGET-APIKEY finns inte
  14. [Michael Friis](https://www.codeplex.com/site/users/view/friism) (@friism)
    • [#3278](https://nuget.codeplex.com/workitem/3278) – Åtgärdar NuGet.Build-målfilen så att den fungerar korrekt på MonoDevelop
  15. [Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
    • Förbättra prestanda för återställningskommandon genom att öka parallelliseringen

Viktiga funktioner i versionen

NuGet 2.7 introducerar en ny metod för paketåterställning och övervinner också ett stort hinder: Medgivande för paketåterställning är nu aktiverat som standard! Kombinationen av den nya metoden och det implicita medgivandet förenklar drastiskt scenarier för paketåterställning.

Med NuGet-versionerna 2.0, 2.1, 2.2, 2.5 och 2.6 måste användarna uttryckligen tillåta att NuGet laddar ned paket som saknas under bygget. Om det här medgivandet inte uttryckligen hade getts skulle lösningar som hade aktiverat paketåterställning inte skapas förrän användaren hade gett sitt medgivande.

Från och med NuGet 2.7 är medgivande för paketåterställning aktiverat som standard, samtidigt som användarna uttryckligen kan välja bort paketåterställning om så önskas, med hjälp av kryssrutan i NuGets inställningar i Visual Studio. Den här ändringen för implicit medgivande påverkar NuGet i följande miljöer:

  • Förhandsversion av Visual Studio 2013
  • Visual Studio 2012
  • Visual Studio 2010
  • nuget.exe kommandoradsverktyget

Automatisk paketåterställning i Visual Studio

Från och med NuGet 2.7 laddar NuGet automatiskt ned saknade paket under kompilering i Visual Studio, även om paketåterställning inte uttryckligen har aktiverats för lösningen. Den här automatiska paketåterställningen sker i Visual Studio när du skapar ett projekt eller en lösning, men innan MSBuild anropas. Detta ger några betydande fördelar:

  1. Du behöver inte längre använda gesten "Aktivera NuGet-paketåterställning" i din lösning
  2. Projekt behöver inte ändras och NuGet gör inga ändringar i projektet för att säkerställa att paketåterställningen är aktiverad
  3. Alla NuGet-paket, inklusive de som inkluderade MSBuild-importer för props/target-filer, återställs innan MSBuild anropas, vilket säkerställer att dessa rekvisita/mål identifieras korrekt under bygget

För att kunna använda automatisk paketåterställning i Visual Studio behöver du bara vidta en (i)åtgärd:

  1. Kontrollera inte in mappen packages

Det finns flera sätt att utelämna mappen packages från källkontrollen. Mer information finns i avsnittet Paket och källkontroll .

Även om alla användare implicit har valt medgivande för automatisk paketåterställning kan du enkelt välja bort inställningarna för Package Manager i Visual Studio.

Inställningar för Package Manager

Förenklad paketåterställning från Command-Line

NuGet 2.7 introducerar en ny funktion för nuget.exe: nuget.exe restore

Med det här nya återställningskommandot kan du enkelt återställa alla paket för en lösning med ett enda kommando genom att acceptera en lösningsfil eller mapp som ett argument. Dessutom är det argumentet underförstått när det bara finns en enda lösning i den aktuella mappen. Detta innebär att följande funktioner fungerar från en mapp som innehåller en enda lösningsfil (MySolution.sln):

  1. nuget.exe återställ MySolution.sln
  2. nuget.exe återställa .
  3. nuget.exe återställning

Kommandot Återställ öppnar lösningsfilen och hittar alla projekt i lösningen. Därifrån hittar den packages.config filerna för vart och ett av projekten och återställer alla paket som hittas. Den återställer också paket på lösningsnivå som finns i .nuget\packages.config filen. Mer information om det nya återställningskommandot finns i Command-Line-referensen.

Arbetsflödet för ny paketåterställning

Vi är glada över de här ändringarna av paketåterställning eftersom det introducerar ett nytt arbetsflöde. Om du vill utelämna dina paket från källkontrollen committerar du helt enkelt inte den packages mappen. Visual Studio-användare som öppnar och skapar lösningen kommer att se paketen återställas automatiskt. För kommandoradsversioner, anropar du helt enkelt nuget.exe restore innan du anropar msbuild. Du behöver inte längre komma ihåg att använda gesten "Aktivera NuGet-paketåterställning" i din lösning, och vi behöver inte längre ändra dina projekt för att ändra bygget. Och detta ger också en mycket bättre upplevelse för paket som inkluderar MSBuild-importer, särskilt för importer som lagts till via NuGets senaste funktion för automatisk import av rekvisita/målfiler från mappen \build.

Förutom det arbete vi har gjort själva arbetar vi också med några viktiga partner för att avrunda den här nya metoden. Vi har inga konkreta tidslinjer för något av dessa ännu, men varje partner är lika upphetsad som vi är över den nya metoden.

  • Team Foundation Service – De arbetar med att integrera anropet till nuget.exe restore i standardversionsscenarierna.
  • Windows Azure-webbplatser – De tillåter dig att skicka ditt projekt till Azure och få nuget.exe restore anropas innan din webbplats skapas.
  • TeamCity – De uppdaterar sitt NuGet Installer-plugin-program för TeamCity 8.x
  • AppHarbor – De arbetar för att låta dig skicka ditt repo till AppHarbor och ha nuget.exe restore anropat innan din lösning byggs.

Med var och en av partnerna ovan skulle de använda sin egen kopia av nuget.exe och du skulle inte behöva bära nuget.exe i din lösning.

Kända problem

Det fanns två kända problem med nuget.exe återställning med den första 2.7-versionen, men de åtgärdades den 2013-09-06 med en uppdatering av NuGet.CommandLine-paketet. Den här uppdateringen är också tillgänglig på [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605) CodePlex. Att köra nuget.exe update -self kommer att uppdatera till den senaste versionen.

De fasta var:

  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)

Det finns också ett känt problem med det nya arbetsflödet för paketåterställning där [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625). Det här problemet har åtgärdats i NuGet 2.7.1.

Fel/varningar för projektretargeting och uppgraderingsversion

Efter att du många gånger har ändrat målplattform eller uppgraderat ditt projekt, hittar du att vissa NuGet-paket inte fungerar som det ska. Tyvärr finns det inget som tyder på detta och då finns det ingen vägledning om hur du hanterar det. Med NuGet 2.7 använder vi nu vissa Visual Studio-händelser för att identifiera när du har ändrat målinriktning eller uppgraderat ditt projekt på ett sätt som påverkar dina installerade NuGet-paket.

Om vi upptäcker att något av dina paket påverkades av omtargetingen eller uppgraderingen skapar vi omedelbara byggfel som meddelar dig. Förutom det omedelbara byggfelet bevarar vi även en requireReinstallation="true" flagga i filen packages.config för alla paket som påverkades av omtargetingen, och varje efterföljande version i Visual Studio ger upphov till byggvarningar för dessa paket.

Även om NuGet inte kan vidta automatiska åtgärder för att installera om de berörda paketen hoppas vi att den här indikationen och varningen hjälper dig att identifiera när du behöver installera om paket. Vi arbetar också med dokumentation om vägledning för paketominstallation som dessa felmeddelanden leder dig till.

Standardinställningar för NuGet-konfiguration

Många företag använder NuGet internt, men har haft svårt att vägleda sina utvecklare att använda interna paketkällor i stället för nuget.org. NuGet 2.7 introducerar en konfigurationsstandardfunktion som gör att standardvärden för hela datorn kan anges för:

  1. Aktiverade paketkällor
  2. Registrerade, men inaktiverade paketkällor
  3. Standard-nuget.exe push-källa

Var och en av dessa kan nu konfigureras i en fil som finns på %ProgramData%\NuGet\NuGetDefaults.Config. Om den här konfigurationsfilen anger paketkällor, registreras inte standardpaketkällan från nuget.org automatiskt, och istället registreras de som anges i NuGetDefaults.Config.

Även om det inte krävs för att använda den här funktionen förväntar vi oss att företag distribuerar NuGetDefaults.Config filer med hjälp av grupprincip.

Observera att den här funktionen aldrig kommer att orsaka att en paketkälla tas bort från en utvecklares NuGet-inställningar. Det innebär att om utvecklaren redan har använt NuGet och därför har nuget.org paketkällan registrerad tas den inte bort när en NuGetDefaults.Config fil har skapats.

Mer information om den här funktionen finns i NuGet-konfigurationsstandarder .

Byta namn på standardpaketkällan

NuGet har alltid registrerat en standardpaketkälla med namnet "NuGet official package source" som pekar på nuget.org. Det namnet var omständligt och det angav inte heller var det faktiskt pekade. För att åtgärda dessa två problem har vi bytt namn på den här paketkällan till att helt enkelt "nuget.org" i användargränssnittet. Url:en för paketkällan har också ändrats så att den innehåller prefixet "www". När du har använt NuGet 2.7 uppdateras din befintliga "NuGet officiella paketkälla" automatiskt till "nuget.org" som dess namn och "https://www.nuget.org/api/v2/" som url.

Prestandaförbättringar

Vi har gjort vissa prestandaförbättringar i 2.7, vilket ger mindre minnesavtryck, mindre diskanvändning och snabbare paketinstallation. Vi har också gjort smartare frågor till OData-baserade flöden, vilket minskar den totala nyttolasten.

Nya API:er för utökningsbarhet

Vi har lagt till några nya API:er i våra utökningsbarhetstjänster för att fylla tomrummet med saknade funktioner i tidigare versioner.

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

Development-Only-beroenden

Den här funktionen bidrogs av Adam Ralph och gör det möjligt för paketförfattare att deklarera beroenden som endast användes vid utvecklingstid och inte kräver paketberoenden. Genom att lägga till ett developmentDependency="true" attribut i ett paket i packages.confignuget.exe pack kommer paketet inte längre att inkluderas som ett beroende.

Stöd för Visual Studio 2010 Express för Windows Phone har tagits bort

Den nya paketåterställningsmodellen i 2.7 implementeras av en ny VSPackage som skiljer sig från huvud-NuGet VSPackage. På grund av ett tekniskt problem fungerar inte den här nya VSPackage korrekt i Visual Studio 2010 Express för Windows Phone SKU eftersom vi delar samma kodbas med andra Visual Studio-SKU:er som stöds. Från och med NuGet 2.7 tar vi därför bort stödet för Visual Studio 2010 Express för Windows Phone från det publicerade tillägget. Stöd för Visual Studio 2010 Express for Web ingår fortfarande i det primära tillägget som publiceras i Visual Studio-tilläggsgalleriet.

Eftersom vi är osäkra på hur många utvecklare som fortfarande använder NuGet i den versionen/versionen av Visual Studio publicerar vi ett separat Visual Studio-tillägg specifikt för dessa användare och publicerar det på CodePlex (i stället för Visual Studio-tilläggsgalleriet). Vi planerar inte att fortsätta att underhålla tillägget, men om detta påverkar dig kan du meddela oss genom att lämna in ett problem på CodePlex.

Om du vill ladda ned NuGet Package Manager (för Visual Studio 2010 Express för Windows Phone) går du till sidan [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605) .

Felkorrigeringar

Förutom dessa funktioner innehåller den här versionen av NuGet även många andra felkorrigeringar. Det fanns totalt 97 problem som togs upp i versionen. En fullständig lista över arbetsobjekt som har åtgärdats i NuGet 2.7 finns i [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all).