Lire en anglais

Partager via


Notes de publication de NuGet 2.5

Notes de publication de 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 grande que nous nous sommes sentis obligés de passer outre les versions 2.3 et 2.4. À ce jour, il s’agit de la plus grande version 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) dans la version.

Remerciements

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

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847) – Ajout de MonoAndroid, MonoTouch et MonoMac à la liste des identificateurs connus du framework cible
  2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
    • [#2865](https://nuget.codeplex.com/workitem/2865) – Correction de l’orthographe du NuGet.targets pour un système d’exploitation qui respecte la casse
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Création de la génération de solution sur Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Correction de 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) – La commande nuget.exe 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) – Modification du code de gestion XML 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)
    • Correction des 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) – Gestion des dépendances descripteur 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 des mots de passe en texte clair lors du stockage des identifiants de la source du package dans les fichiers 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) Correction de la description de l’aide Get-Package

Nous remercions également les personnes suivantes pour trouver des bogues dans NuGet 2.5 Bêta/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 de la version

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

L’une des fonctionnalités les plus demandées a toujours été la possibilité de remplacer les fichiers de contenu qui existent déjà sur le disque lorsqu’ils sont inclus dans un package NuGet. À partir 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.

Overwrite content files

« nuget.exe update » 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 lorsque le fichier d’un package existe déjà dans le projet cible. Définissez la valeur sur « Overwrite » (Remplacer) pour toujours remplacer les fichiers. Définissez la valeur sur « Ignore » (Ignorer) pour ignorer les fichiers. Si l’action n’est pas spécifiée, il posera la question 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 de \lib, \content et \tools, vous pouvez désormais inclure un dossier \build dans votre package. Sous ce dossier, vous pouvez placer deux fichiers avec des noms fixes, {packageid}.targets ou {packageid}.props. Ces deux fichiers peuvent être directement sous build ou sous des dossiers spécifiques à l’infrastructure, comme les autres dossiers. La règle de sélection du dossier framework le mieux adapté est exactement la même que dans celles-ci.

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

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

Avant la version 2.5, dans le fichier .nuspec, 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 fichier .nuspec :

  1. Recherchez le dossier lib approprié pour le framework cible et obtenez la liste des assemblys de ce dossier
  2. Trouvez séparément le groupe de références approprié pour le framework cible et obtenez la liste des assemblages de ce groupe. Le groupe de références sans framework cible spécifié est le groupe de secours.
  3. Rechercher 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 dossiers lib.

Remarque : vous devez actuellement utiliser nuget.exe pack pour profiter de cette fonctionnalité ; NuGet Package Explorer ne le prend pas encore en charge.

Bouton « Tout mettre à jour » 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 également via l’interface utilisateur.

Pour essayer cette fonctionnalité :

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

Update All button in the dialog

Amélioration de la prise en charge des références de projet pour nuget.exe Pack

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

  1. Si le projet référencé a un fichier .nuspec correspondant, par exemple, il existe un fichier appelé proj1.nuspec dans le même dossier que proj1.csproj, ce projet est alors ajouté en tant que dépendance au package, à l’aide de l’ID et de la lecture de la version à partir du fichier .nuspec.
  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 de manière récursive.
  3. Tous les fichiers .pdb, .exe et DLL sont ajoutés.
  4. Le reste de 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 fichier .nuspec, sinon, il fait partie du package.

Plus de détails 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 fonctionnalités .nuspec 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 signaux visuels seront fournis à l’utilisateur indiquant que le package ne sera pas installable. L’utilisateur sera alors 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, lors de l’installation d’un package qui dépendait d’un package déjà installé dans le projet, la dépendance était mise à jour dans le cadre de la nouvelle installation, même si la version existante satisfaisait la dépendance.

À partir de NuGet 2.5, si une condition de version de dépendance est déjà satisfaite, la dépendance ne sera pas mise à jour lors des autres installations de package.

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 mettra automatiquement à jour le package 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 le package 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 le [work item](https://nuget.codeplex.com/workitem/1681) détaillé ainsi que le [discussion thread](https://nuget.codeplex.com/discussions/436712) associé.

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

Si vous résolvez des problèmes liés à nuget.exe ou que vous souhaitez simplement savoir quelles requêtes HTTP sont effectuées pendant les opérations, le commutateur « -verbosity detailed » génère désormais toutes les requêtes HTTP effectuées.

HTTP output from nuget.exe

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

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

À partir de NuGet  2.5, si nuget.exe identifie une source UNC/dossier, il effectue la copie de 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

Les commandes nuget.exe 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 de 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.