Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Notes de publication de NuGet 1.0 et 1.1
NuGet 1.2 a été publié le 30 mars 2011.
Nouvelles fonctionnalités
Prise en charge du profil de framework
À partir du début, NuGet a pris en charge la mise en place de bibliothèques ciblant différents frameworks. Toutefois, les packages peuvent contenir des assemblys qui ciblent des profils spécifiques tels que le profil Windows Phone. Pour cibler un profil spécifique d’une infrastructure, ajoutez un tiret suivi de l’abréviation du profil. Par exemple, pour cibler SilverLight s’exécutant sur un Windows Phone (également appelé Windows Phone 7), vous pouvez placer un assembly dans le dossier sl3-wp, comme illustré dans la capture d’écran suivante.
Vous pouvez demander pourquoi nous n’avons pas simplement choisi d’utiliser « wp7 » comme moniker. En partie, nous prévoyons que Windows Phone 7 puisse exécuter une version plus récente de Silverlight à l’avenir, auquel cas vous devrez peut-être être plus spécifique sur le profil d’infrastructure que vous ciblez.
Ajouter automatiquement des redirections de liaison
Lors de l’installation d’un package avec des assemblys fortement nommés, 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 pour que le projet compile et les ajouter automatiquement. La partie 3 de la série de billets de blog de David Ebbo sur NuGet Versioning intitulée « Unification via binding Redirects » couvre l’objectif de cette fonctionnalité dans plus de détails.
Spécification de références d’assembly framework (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 du framework. Toutefois, dans certains cas, il est important, par exemple lorsque le développeur doit coder sur des types dans cet assembly afin d’utiliser votre package. Le nouvel frameworkAssemblies élément, 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 Framework dans le GAC. Prenez note de l'accent mis sur l'assemblage du Framework.
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 .
| Caractéristique | Descriptif |
|---|---|
| assemblyName |
Obligatoire. Nom de l'assemblage tel que System.Net. |
| targetFramework | Facultatif. Permet de spécifier un nom d’infrastructure et de profil (ou alias) auquel cet assembly de framework s’applique, par exemple « net40 » ou « sl4 ». Utilise le même format décrit dans la prise en charge de plusieurs frameworks cibles. |
<frameworkAssemblies>
<frameworkAssembly assemblyName="System.ComponentModel.DataAnnotations" targetFramework="net40" />
<frameworkAssembly assemblyName="System.ServiceModel" targetFramework="net40" />
</frameworkAssemblies>
nuget.exe est maintenant 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 le spécifier chaque fois que vous envoyez un package. Pour plus d’informations sur l’enregistrement de votre clé API avec nuget.exe, lisez la documentation sur la publication d’un package.
Explorateur de packages
L’Explorateur de packages 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 fonctionnalités/correctifs
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. Dans tous les cas, 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é du 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 du complément VS NuGet (par exemple, 1.1). Si vous obtenez un message d'erreur mentionnant un problème de schéma incompatible, c'est cette erreur qui se produit. Mettez à 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 NuGet, puis l’installer. Ceci 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é correctement signée. Cette version n’a été mise à disposition que sur le site web CodePlex pendant une courte période, de sorte que ce problème ne devrait pas affecter trop de personnes.