Releaseopmerkingen voor NuGet 2.1

Releaseopmerkingen | voor NuGet 2.0Releaseopmerkingen voor NuGet 2.2

NuGet 2.1 is uitgebracht op 4 oktober 2012.

Hiërarchische Nuget.Config

NuGet 2.1 biedt u meer flexibiliteit bij het beheren van NuGet-instellingen door recursief de mapstructuur op te lopen op zoek naar NuGet.Config bestanden en vervolgens de configuratie te bouwen vanuit de set gevonden bestanden. Denk bijvoorbeeld aan het scenario waarin een team een interne pakketopslagplaats heeft voor CI-builds van andere interne afhankelijkheden. De mapstructuur voor een afzonderlijk project kan er als volgt uitzien:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Als pakketherstel is ingeschakeld voor de oplossing, bestaat ook de volgende map:

C:\myteam\solution1\.nuget

Om ervoor te zorgen dat de interne pakketopslagplaats van het team beschikbaar is voor alle projecten waaraan het team werkt, terwijl het niet beschikbaar wordt gemaakt voor elk project op de computer, kunnen we een nieuw Nuget.Config-bestand maken en in de map c:\myteam plaatsen. Er is geen manier om een map met pakketten per project te specificeren.

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

We kunnen nu zien dat de bron is toegevoegd door de opdracht 'nuget.exe bronnen' uit te voeren vanuit elke map onder c:\myteam, zoals hieronder wordt weergegeven:

NuGet.Config bestanden worden in de volgende volgorde gezocht:

1. .nuget\Nuget.Config
2. Recursieve doorloop van projectmap naar rootmap
3. Globaal Nuget.Config (%appdata%\NuGet\Nuget.Config)

De configuraties worden dan toegepast in de omgekeerde volgorde, wat betekent dat de globale Nuget.Config eerst wordt toegepast, gevolgd door de gedetecteerde Nuget.Config-bestanden van de hoofdmap naar de projectmap, gevolgd door .nuget\Nuget.Config. Dit is met name belangrijk als u het <clear/> element gebruikt om een set items uit de configuratie te verwijderen.

Locatie van map 'pakketten' opgeven

In het verleden heeft NuGet de pakketten van een oplossing beheerd uit een bekende map 'pakketten' die zich onder de hoofdmap van de oplossing bevinden. Voor ontwikkelteams met veel verschillende oplossingen waarop NuGet-pakketten zijn geïnstalleerd, kan dit ertoe leiden dat hetzelfde pakket op veel verschillende plaatsen op het bestandssysteem wordt geïnstalleerd.

NuGet 2.1 biedt gedetailleerdere controle over de locatie van de pakketmap via het repositoryPath element in het NuGet.Config bestand. Als u voortbouwt op het vorige voorbeeld van hiërarchische ondersteuning voor Nuget.Config, wordt ervan uitgegaan dat alle projecten onder C:\myteam\ dezelfde map met pakketten delen. Om dit te bereiken, voegt u gewoon de volgende vermelding toe aan c:\myteam\Nuget.Config.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

In dit voorbeeld geeft het gedeelde Nuget.Config bestand een map met gedeelde pakketten op voor elk project dat wordt gemaakt onder C:\myteam, ongeacht de diepte. Als u een bestaande map met pakketten onder de hoofdmap van uw oplossing hebt, moet u deze verwijderen voordat NuGet pakketten op de nieuwe locatie plaatst.

Ondersteuning voor draagbare bibliotheken

Draagbare bibliotheken is een functie die voor het eerst is geïntroduceerd met .NET 4 waarmee u assembly's kunt bouwen die zonder aanpassingen op verschillende Microsoft-platforms kunnen werken, van versies van the.NET Framework naar Silverlight naar Windows Phone en zelfs Xbox 360 (hoewel NuGet op dit moment geen ondersteuning biedt voor het doel van de Draagbare Xbox-bibliotheek). Door de pakketconventies voor frameworkversies en -profielen uit te breiden, ondersteunt NuGet 2.1 nu draagbare bibliotheken door u in staat te stellen pakketten te maken die samengestelde framework- en profieldoelmappen lib hebben.

Bekijk bijvoorbeeld de volgende doelplatforms van een draagbare klassebibliotheek.

Nadat de bibliotheek is gemaakt en de opdracht nuget.exe pack MyPortableProject.csproj wordt uitgevoerd, kan de nieuwe mapstructuur van het draagbare bibliotheekpakket worden bekeken door de inhoud van het gegenereerde NuGet-pakket te bekijken.

Zoals u kunt zien, volgt de naamconventie van de draagbare bibliotheekmap het patroon 'portable-{framework 1}+{framework n}' waarbij de framework-id's de bestaande frameworknaam en versieconventies volgen. Een uitzondering op de naam- en versieconventies vindt u in de framework-id die wordt gebruikt voor Windows Phone. Deze moniker moet de frameworknaam 'wp' (wp7, wp71 of wp8) gebruiken. Het gebruik van 'silverlight-wp7' resulteert bijvoorbeeld in een fout.

Wanneer u het pakket installeert dat is gemaakt op basis van deze mapstructuur, kan NuGet nu de framework- en profielregels toepassen op meerdere doelen, zoals opgegeven in de mapnaam. Achter de overeenkomende regels van NuGet is het principe dat 'specifiekere' doelen voorrang krijgen op 'minder specifieke' doelen. Dit betekent dat monikers die gericht zijn op een specifiek platform altijd de voorkeur krijgen boven draagbare platforms als ze beide compatibel zijn met een project. Als er meerdere portable platforms compatibel zijn met een project, geeft NuGet bovendien de voorkeur aan de set platformen die het meest overeenkomen met het project dat naar het pakket verwijst.

Projecten Doelgericht op Windows 8 en Windows Phone 8

Naast het toevoegen van ondersteuning voor draagbare bibliotheekprojecten biedt NuGet 2.1 nieuwe framework monikers voor zowel Windows 8 Store- als Windows Phone 8-projecten, evenals enkele nieuwe algemene monikers voor Windows Store- en Windows Phone-projecten die gemakkelijker te beheren zijn in toekomstige versies van de respectieve platforms.

Voor Windows 8 Store-toepassingen zien de id's er als volgt uit:

NuGet 2.0 en eerder	NuGet 2.1
winRT45, . NETCore45	Windows, Windows8, win, win8

Voor Windows Phone-projecten zien de id's er als volgt uit:

Telefoon besturingssysteem	NuGet 2.0 en eerder	NuGet 2.1
Windows Phone 7	silverlight3-wp	wp, wp7, WindowsPhone, WindowsPhone7
Windows Phone 7.5 (Mango)	silverlight4-wp71	wp71, WindowsPhone71
Windows Phone 8	(niet ondersteund)	wp8, WindowsPhone8

In alle bovenstaande wijzigingen blijven de oude frameworknamen volledig ondersteund door NuGet 2.1. In de toekomst moeten de nieuwe namen worden gebruikt, omdat ze stabieler zijn in toekomstige versies van de respectieve platforms. De nieuwe namen worden *niet* ondersteund in versies van NuGet vóór 2.1, dus plan dienovereenkomstig voor wanneer u de overstap moet maken.

Verbeterd zoeken in het dialoogvenster Package Manager

In de afgelopen verschillende iteraties zijn wijzigingen geïntroduceerd in de NuGet-galerie die de snelheid en relevantie van pakketzoekopdrachten aanzienlijk heeft verbeterd. Deze verbeteringen waren echter beperkt tot de nuget.org website. NuGet 2.1 maakt de verbeterde zoekervaring beschikbaar via het dialoogvenster NuGet-pakketbeheer. Stel dat u het Windows Azure Caching Preview-pakket wilt vinden. Een redelijke zoekquery voor dit pakket kan 'Azure Cache' zijn. In eerdere versies van het dialoogvenster Pakketbeheer wordt het gewenste pakket niet eens weergegeven op de eerste pagina met resultaten. In NuGet 2.1 wordt het gewenste pakket nu echter boven aan de zoekresultaten weergegeven.

Pakketupdate afdwingen

Vóór NuGet 2.1 slaat NuGet het bijwerken van een pakket over wanneer er geen hoog versienummer was. Dit heeft wrijving geïntroduceerd voor bepaalde scenario's, met name in het geval van build- of CI-scenario's waarbij het team het versienummer van het pakket niet met elke build wilde verhogen. Het gewenste gedrag was om een update af te dwingen, ongeacht. NuGet 2.1 lost dit op met de vlag 'opnieuw installeren'. Eerdere versies van NuGet zouden bijvoorbeeld resulteren in het volgende wanneer wordt geprobeerd een pakket bij te werken dat geen recentere pakketversie heeft:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Met de vlag voor opnieuw installeren wordt het pakket bijgewerkt, ongeacht of er een nieuwere versie is.

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.

Een ander scenario waarin de reïnstallatievlag nuttig is, is dat van het heroriënteren van frameworks. Wanneer u het doelframework van een project wijzigt (bijvoorbeeld van .NET 4 naar .NET 4.5), kunnen Update-Package -Reinstall verwijzingen naar de juiste assembly's bijwerken voor alle NuGet-pakketten die in het project zijn geïnstalleerd.

Pakketbronnen bewerken in Visual Studio

In eerdere versies van NuGet moet u een pakketbron bijwerken vanuit het dialoogvenster met Visual Studio-opties om de pakketbron te verwijderen en opnieuw toe te voegen. NuGet 2.1 verbetert deze werkstroom door update te ondersteunen als een eersteklas functie van de gebruikersinterface van de configuratie.

Oplossingen voor bugs

NuGet 2.1 bevat veel bugfixes. Voor een volledige lijst met werkitems die zijn opgelost in NuGet 2.0, bekijkt u de [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).