Partager via

Notes de publication de NuGet 2.5

Notes de publication NuGet 2.2.1 | Notes de publication de NuGet 2.6

NuGet 2.5 a été publié le 25 avril 2013. Cette version était si importante que nous avons dû ignorer les versions 2.3 et 2.4 ! À ce jour, il s'agit de la plus grande publication que nous avons eue pour NuGet, avec plus de [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) inclus dans la publication.

Remerciements

Nous tenons à remercier les contributeurs externes suivants pour leurs contributions significatives à NuGet 2.5 :

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847) - Ajoutez MonoAndroid, MonoTouch et MonoMac à la liste des identificateurs de framework cible connus.
  2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
    • [#2865](https://nuget.codeplex.com/workitem/2865) - Corriger l’orthographe de NuGet.targets pour un système d’exploitation sensible à la casse
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Compilez la solution sur Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Corriger l’échec des tests unitaires sur Mono.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920) - nuget.exe commande pack ne propage pas les propriétés à MSBuild
  6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
    • [#1511](https://nuget.codeplex.com/workitem/1511) - Code de gestion XML modifié pour conserver la mise en forme.
  7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • Ajout de mots reconnus au dictionnaire personnalisé pour permettre à build.cmd de réussir.
  8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
    • Corrigez les tests unitaires lors de l’exécution dans VS localisé.
  9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
    • Interface extraite de PackageService
  10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936) - Gérer les dépendances de projet lors de l’empaquetage
  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) - Prise en charge du mot de passe en texte clair lors du stockage des informations d’identification de la source du package dans les fichiers nuget.config
  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) - Corriger la description de l’aide de Get-Package

Nous apprécions également les personnes suivantes pour trouver des bogues avec NuGet 2.5 Beta/RC qui ont été approuvés et corrigés avant la version finale :

  1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
    • [#3200](https://nuget.codeplex.com/workitem/3200) - MSTest rompu avec les dernières builds NuGet 2.4 et 2.5

Fonctionnalités notables dans la version

Autoriser les utilisateurs à remplacer les fichiers de contenu qui existent déjà

L’une des fonctionnalités les plus demandées à tout moment a été la possibilité de remplacer les fichiers de contenu qui existent déjà sur le disque lorsqu’ils sont inclus dans un package NuGet. À compter de NuGet 2.5, ces conflits sont identifiés et vous êtes invité à remplacer les fichiers, alors qu’auparavant ces fichiers étaient toujours ignorés.

Remplacer les fichiers de contenu

«nuget.exe mise à jour » et « Install-Package » ont désormais une nouvelle option « -FileConflictAction » pour définir une valeur par défaut pour les scénarios de ligne de commande.

Définissez une action par défaut lorsqu’un fichier à partir d’un package existe déjà dans le projet cible. Définissez sur « Remplacer » pour toujours remplacer les fichiers existants. Définissez la valeur « Ignorer » pour ignorer les fichiers. S’il n’est pas précisé, il sollicitera pour chaque fichier en conflit.

Importation automatique des fichiers cibles et de propriétés MSBuild

Un nouveau dossier conventionnel a été créé au niveau supérieur du package NuGet. En tant qu’homologue à \lib, \contentet \tools, vous pouvez désormais inclure un \build dossier dans votre package. Sous ce dossier, vous pouvez placer deux fichiers avec des noms fixes ou {packageid}.targets{packageid}.props. Ces deux fichiers peuvent être soit directement sous build, soit sous des dossiers spécifiques à l’infrastructure, comme c'est le cas pour les autres dossiers. La règle de sélection du dossier framework le mieux adapté est exactement la même que dans celles-ci.

Lorsque NuGet installe un package avec des fichiers de build, il ajoutera un élément MSBuild <Import> dans le fichier projet pointant vers les fichiers .targets et .props. Le .props fichier est ajouté en haut, tandis que le .targets fichier est ajouté au bas.

Spécifier différentes références par plateforme à l’aide d’un <References/> élément

Avant la version 2.5, dans .nuspec le fichier, l’utilisateur ne peut spécifier que les fichiers de référence, à ajouter pour toute l’infrastructure. Maintenant que cette nouvelle fonctionnalité est disponible dans la version 2.5, l’utilisateur peut créer l’élément <reference/> pour chacune des plateformes prises en charge, par exemple :

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

Voici le flux pour savoir comment NuGet ajoute des références à des projets en fonction du .nuspec fichier :

  1. Recherchez le lib dossier approprié pour l’infrastructure cible et obtenez la liste des assemblys de ce dossier
  2. Recherchez séparément le groupe de références approprié pour l’infrastructure cible et obtenez la liste des assemblys de ce groupe. Le groupe de références sans framework cible spécifié est le groupe de secours.
  3. Recherchez l’intersection des deux listes et utilisez-la comme références à ajouter

Cette nouvelle fonctionnalité permet aux auteurs de packages d’utiliser la fonctionnalité Références pour appliquer des sous-ensembles d’assemblys à différents frameworks lorsqu’ils devront autrement transporter des assemblys en double dans plusieurs lib dossiers.

Remarque : vous devez actuellement utiliser nuget.exe pack pour utiliser cette fonctionnalité ; L’Explorateur de packages NuGet ne le prend pas encore en charge.

Bouton Mettre à jour tout pour autoriser la mise à jour de tous les packages en même temps

La plupart d’entre vous connaissent l’applet de commande PowerShell « Update-Package » pour mettre à jour tous vos packages ; il existe désormais un moyen simple de le faire via l’interface utilisateur.

Pour essayer cette fonctionnalité :

  1. Créer une application MVC ASP.NET
  2. Lancez la boîte de dialogue « Gérer les packages NuGet »
  3. Sélectionnez « Mises à jour »
  4. Cliquez sur le bouton « Mettre à jour tout »

Bouton Mettre à jour tout dans la boîte de dialogue

Prise en charge améliorée des références de projet pour nuget.exe Pack

À présent, la commande pack de nuget.exe gère les projets référencés avec les règles suivantes :

  1. Si le projet référencé a un fichier correspondant .nuspec , par exemple, il existe un fichier appelé proj1.nuspec dans le même dossier que proj1.csproj, ce projet est ajouté en tant que dépendance au package, à l’aide de l’ID et de la version lues à partir du .nuspec fichier.
  2. Sinon, les fichiers du projet référencé sont regroupés dans le package. Ensuite, les projets référencés par ce projet seront traités à l’aide des mêmes règles récursivement.
  3. Toutes les DLL, .pdb, et .exe fichiers sont ajoutés.
  4. Tous les autres fichiers de contenu sont ajoutés.
  5. Toutes les dépendances sont fusionnées.

Cela permet à un projet référencé d’être traité comme une dépendance s’il existe un .nuspec fichier, sinon, il fait partie du package.

Plus d’informations ici : [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Ajouter une propriété « Version NuGet minimale » aux packages

Un nouvel attribut de métadonnées appelé « minClientVersion » peut maintenant indiquer la version minimale du client NuGet requise pour consommer un package.

Cette fonctionnalité permet à l’auteur du package de spécifier qu’un package fonctionne uniquement après une version particulière de NuGet. À mesure que de nouvelles .nuspec fonctionnalités sont ajoutées après NuGet 2.5, les packages pourront revendiquer une version minimale de NuGet.

<metadata minClientVersion="2.6">

Si l’utilisateur a installé NuGet 2.5 et qu’un package est identifié comme nécessitant la version 2.6, des indications visuelles seront fournies à l’utilisateur indiquant que le package ne sera pas installable. L’utilisateur sera ensuite guidé pour mettre à jour sa version de NuGet.

Cela permettra d’améliorer l’expérience existante dans laquelle les packages commencent à s’installer, mais échouent, indiquant qu’une version de schéma non reconnue a été identifiée.

Les dépendances ne sont plus inutilement mises à jour pendant l’installation du package

Avant NuGet 2.5, lorsqu’un package a été installé qui dépendait d’un package déjà installé dans le projet, la dépendance serait mise à jour dans le cadre de la nouvelle installation, même si la version existante satisfait la dépendance.

À compter de NuGet 2.5, si une version de dépendance est déjà satisfaite, la dépendance n’est pas mise à jour pendant d’autres installations de package.

Le scénario :

  1. Le référentiel source contient le package B avec la version 1.0.0 et 1.0.2. Il contient également le package A qui a une dépendance sur B (>= 1.0.0).
  2. Supposons que le projet actuel a déjà installé le package B version 1.0.0. Vous souhaitez maintenant installer le package A.

Dans NuGet 2.2 et versions antérieures :

  • Lors de l’installation du package A, NuGet met automatiquement à jour B vers la version 1.0.2, même si la version existante 1.0.0 satisfait déjà à la contrainte de version de dépendance, qui est >= 1.0.0.

Dans NuGet 2.5 et versions ultérieures :

  • NuGet ne met plus à jour B, car il détecte que la version 1.0.0 existante satisfait à la contrainte de version de dépendance.

Pour plus d’informations sur cette modification, lisez les détails [work item](https://nuget.codeplex.com/workitem/1681) ainsi que les éléments associés [discussion thread](https://nuget.codeplex.com/discussions/436712).

nuget.exe génère des requêtes http avec une précision détaillée

Si vous rencontrez des problèmes avec nuget.exe ou si vous êtes simplement curieux de savoir quelles requêtes HTTP sont effectuées pendant les opérations, l'option « -verbosity détaillé » génère désormais toutes les requêtes HTTP effectuées.

Sortie HTTP de nuget.exe

nuget.exe push prend désormais en charge les sources UNC et de dossiers

Avant NuGet 2.5, si vous avez tenté d’exécuter «nuget.exe push » vers une source de package en fonction d’un chemin d’accès UNC ou d’un dossier local, le push échouerait. Avec la fonctionnalité de configuration hiérarchique récemment ajoutée, il était devenu courant pour nuget.exe de devoir cibler une source UNC/dossier ou une galerie NuGet basée sur HTTP.

À compter de NuGet 2.5, si nuget.exe identifie une source UNC/dossier, il effectue la copie du fichier vers la source.

La commande suivante fonctionne désormais :

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

nuget.exe prend en charge les fichiers config spécifiés explicitement

nuget.exe commandes qui accèdent à la configuration (à l’exception de « spec » et « pack ») prennent désormais en charge une nouvelle option « -ConfigFile », ce qui force l’utilisation d’un fichier config spécifique à la place du fichier de configuration par défaut à %AppData%\nuget\Nuget.Config.

Exemple :

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

Prise en charge des projets natifs

Avec NuGet 2.5, les outils NuGet sont désormais disponibles pour les projets natifs dans Visual Studio. Nous nous attendons à ce que la plupart des packages natifs utilisent la fonctionnalité d’importation MSBuild ci-dessus, à l’aide d’un outil créé par le projet CoApp. Pour plus d’informations, consultez les détails de l’outil sur le site web coapp.org.

Le nom du framework cible « natif » est introduit pour que les packages incluent des fichiers dans \build, \content et \tools lorsque le package est installé dans un projet natif. Le dossier « lib » n’est pas utilisé pour les projets natifs.

  • Last updated on