Lire en anglais

Partager via


Notes de publication de NuGet 1.2

Notes de publication de NuGet 1.0 et 1.1 | Notes de publication de NuGet 1.3

NuGet 1.2 a été publié le 30 mars 2011.

Nouvelles fonctionnalités

Support du profil de cadre

À partir du début, NuGet a pris en charge les bibliothèques ciblant différents cadres. Toutefois, les packages peuvent maintenant contenir des assemblys qui ciblent des profils spécifiques tels que le profil Windows Phone (téléphone Windows). Pour cibler un profil spécifique d’un cadre, ajoutez un tiret suivi de l’abréviation du profil. Par exemple, pour cibler SilverLight s’exécutant sur un téléphone Windows (également appelé Windows Phone 7), vous pouvez placer un assembly dans le dossier sl3-wp, comme illustré dans la capture d’écran suivante.

Framework Profile Folder Layout

Vous pouvez demander pourquoi nous n’avons pas simplement choisi d’utiliser « wp7 » comme moniker. En partie, nous prévoyons que Windows Phone 7 pourrait exécuter une version plus récente de Silverlight à l’avenir, auquel cas vous devrez peut-être être plus spécifique sur le profil de cadre que vous ciblez.

Ajouter automatiquement des redirections de liaison

Lors de l’installation d’un package avec des assemblys nommés forts, NuGet peut désormais détecter les cas où le projet nécessite que les redirections de liaison soient ajoutées au fichier de configuration afin que le projet les compile et les ajoute automatiquement. La partie 3 de la série de billets de blog de David Ebbo sur le contrôle de version NuGet Versioning intitulée « Unification via des redirections de liaison » couvre l’objectif de cette fonctionnalité dans plus de détails.

Spécifications de références d’assembly de cadre (GAC)

Dans certains cas, un package peut dépendre d’un assembly qui se trouve dans le .NET Framework. À proprement parler, il n’est pas toujours nécessaire que le consommateur de votre package référence l’assembly de cadre. Toutefois, dans certains cas, c’est important, par exemple lorsque le développeur doit écrire du code sur des types dans cet assembly afin d’utiliser votre package. Le nouvel élément frameworkAssemblies, un élément enfant de l’élément de métadonnées, vous permet de spécifier un ensemble d’éléments frameworkAssembly pointant vers un assembly de cadre dans le GAC. Notez l’accent mis sur l’assembly de cadre. Ces assemblys ne sont pas inclus dans votre package, car ils sont supposés être sur chaque ordinateur dans le cadre du .NET Framework. Le tableau suivant répertorie les attributs de l’élément frameworkAssembly.

Attribut Description
assemblyName Obligatoire. Nom de l’assembly tel que System.Net.
targetFramework Facultatif. Permet de spécifier un nom de cadre et une identité (ou alias) auquel cet assembly de framework s’applique, par exemple « net40 » ou « sl4 ». Utilise le même format décrit dans le support de plusieurs versions cibles de .Net Framework.
  <frameworkAssemblies>
    <frameworkAssembly assemblyName="System.ComponentModel.DataAnnotations" targetFramework="net40" />
    <frameworkAssembly assemblyName="System.ServiceModel" targetFramework="net40" />
  </frameworkAssemblies>

nuget.exe est désormais en mesure de stocker les informations d’identification de la clé API

Lorsque vous utilisez l’outil en ligne de commande nuget.exe, vous pouvez maintenant utiliser la commande SetApiKey pour stocker votre clé API. De cette façon, vous n’aurez pas besoin de spécifier cela chaque fois que vous envoyez un package. Pour plus de détails sur l’enregistrement de votre clé API avec nuget.exe, lisez la documentation sur la publication d’un package.

Explorateur de package

L’Explorateur de package a été mis à jour pour prendre en charge NuGet 1.2. Pour plus d’informations, consultez [Package Explorer release notes](http://nuget.codeplex.com/wikipage?title=New%20features%20in%20NuGet%20Package%20Explorer%201.0).

Autres correctifs de fonctionnalités

La liste précédente était la plus notable des nombreuses fonctionnalités que nous avons implémentées et des bogues que nous avons corrigés. Tout compte fait, nous avons implémenté/corrigé [59 work items](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=All&type=All&priority=All&release=NuGet%201.2&assignedTo=All&component=All&sortField=Votes&sortDirection=Descending&page=0) dans cette version.

Problèmes connus

  • 1.2 Incompatibilité de package : les packages générés avec la dernière version de l’outil en ligne de commande, nuget.exe (> 1.2) ne fonctionnent pas avec les versions antérieures de la macro complémentaire NuGet VS (par exemple, la version 1.1). Si vous rencontrez un message d’erreur mentionnant un schéma incompatible, il s’agit de cette erreur. Veuillez mettre à jour NuGet vers la dernière version.
  • Incompatibilité de NuGet.Server : si vous hébergez un flux NuGet interne à l’aide du projet NuGet.Server, vous devez mettre à jour ce projet avec la dernière version de NuGet.Server.
  • Erreur d’incompatibilité de signature : si vous rencontrez une erreur lors d’une mise à niveau avec un message concernant une incompatibilité de signature, vous devez d’abord désinstaller, puis installer NuGet. Ce problème est répertorié dans notre page Problèmes connus qui fournit plus de détails. Le problème affecte uniquement ceux qui exécutent Visual Studio 2010 SP1 et ont une version de NuGet 1.0 installée qui a été incorrectement signée. Cette version n’a été rendue disponible que sur le site Web CodePlex pendant une courte période, de sorte que ce problème ne devrait pas affecter trop de personnes.