Discussion :

[Hinault Romaric]

Je suis heureux de vous annoncer la publication d'un nouvel article sur le gestionnaire de packages .NET Nuget, désormais très populaire dans l'écosystème .NET.


Cette discussion est ouverte donc pour avoir vos avis, remarques et suggestions sur l'article : Présentation du gestionnaire de packages .NET Nuget.


N'hésitez pas à noter l'article et y ajouter un pouce vers le haut .

[antoine.debyser]

Bonjour

Article très sympa qui donne envie de publier ses librairies sous NuGet.

Par contre j'ai une petite question liée à son utilisation.
Lors du mise à jour d'un package, y'a-t-il un moyen de gérer les incompatibilités, histoire de pas mettre à jour et de se retrouver avec un truc qui compile plus?
Ou de gérer des packages obsolète, type j'ai deplacé mon repository, du coup je tag l'ancien obsolète et donne un lien vers le nouveau...

[Hinault Romaric]

Lors du mise à jour d'un package, y'a-t-il un moyen de gérer les incompatibilités, histoire de pas mettre à jour et de se retrouver avec un truc qui compile plus?

Pendant les mises à jour, pour éviter les problèmes de comptabilités, les versions d'un package peuvent être publiés dans différents dossiers en fonction de la version de la plateforme supportée (.NET3.5, ou 4.0 par exemple). Ainsi, Nuget saura par défaut quelle version il va référencer dans le projet.

Ou de gérer des packages obsolète, type j'ai deplacé mon repository, du coup je tag l'ancien obsolète et donne un lien vers le nouveau...

Cela est bien évidement possible. Cependant, si ton ancien repository est visible, il sera toujours accessible depuis Nuget. Le mieux AMHA est d'archiver la version obsolète et utiliser le même référentiel pour la nouvelle version, du coup, tu n’auras plus besoin de redistribuer un lien vers le nouveau.

Cordialement

[antoine.debyser]

Merci pour les précisions

Pendant les mises à jour, pour éviter les problèmes de comptabilités, les versions d'un package peuvent être publiés dans différents dossiers en fonction de la version de la plateforme supportée (.NET3.5, ou 4.0 par exemple). Ainsi, Nuget saura par défaut quelle version il va référencer dans le projet.

Ce n'est pas vraiment à ça que je pensais.
Disons que je créais une library et la version "X" possède des changements trop radicaux pour que les utilisateurs de la version "X-1" puissent l'utiliser sans modifier leurs codes.
Y'a-t-il un moyen d'indiquer cela?

[Hinault Romaric]

Ce n'est pas vraiment à ça que je pensais.
Disons que je créais une library et la version "X" possède des changements trop radicaux pour que les utilisateurs de la version "X-1" puissent l'utiliser sans modifier leurs codes.
Y'a-t-il un moyen d'indiquer cela?

Dans ce cas, tu peux par exemple dans le fichier XML de spécification, au sein de la balise réservée à la description du package, ajouter cette mention. Ainsi, lors du téléchargement du package avec Nuget, ce message d’alerte sera bien visible pour l'utilisateur.

[noftal]

Bonjour,

Je voudrais bien installer Nuget pour ensuite installer HTML agility pack comme indiqué dans un autre tuto sur ce site, mais je bloque au §III.2 de votre tuto.
J'ai bien réussi à télécharger le NuGet.Tools.vsix mais lorsque je double clique dessus, j'obtiens ce message : "Cette extension n'est installée sur aucun des produits actuellement installés"

Je suis sous Visual Studio 2010 Express et débutant sur ce logiciel.

Ai-je raté un épisode ?

[Invité]

Je suis sous Visual Studio 2010 Express et débutant sur ce logiciel.

D'après la FAQ Nuget :

NuGet requires Visual Studio 2010 Pro/Premium/Ultimate (or newer), Visual Web Developer Express 2010, or any Express SKU of Visual Studio 2012 (or newer).

[clementmarcotte]

Bonjour,

Si mes souvenirs sont exacts, Visual Studio Express 2010, ne peut pas supporter NuGet.

Par contre, le support pour NuGet a été intégré aux versions 2012 Express. Et cela fonctionne bien.