Meilleures pratiques avec Nuget: débogage ou version?
Actuellement, je compile les versions de version avec Nuget pour les versions officielles sur nuget.org, mais je compresse les versions de débogage avec Nuget pour les push de source de symboles vers symbolesource.org.
EDIT: (Jon Skeet, avec un certain biais du développement de Noda Time)
NuGet prend désormais en charge la transmission vers la galerie NuGet et symbolesource.org (ou serveurs similaires), comme indiqué . Malheureusement, il existe ici deux exigences contradictoires:
- Lorsque vous utilisez simplement une bibliothèque sans aucun débogage, vous voulez vraiment une version. C'est à cela que servent les versions de version, après tout.
- Lors du débogage dans une bibliothèque à des fins de diagnostic, vous voulez vraiment une version de débogage avec toutes les optimisations appropriées désactivées. C'est à cela que servent les versions de débogage, après tout.
Ce serait bien, mais NuGet ne permet pas (pour autant que je sache) de publier les versions et les versions de débogage de manière utile, dans le même package.
Donc, les choix sont:
- Distribuez les versions de débogage à tout le monde (comme indiqué dans l'exemple dans les documents) et vivez avec n'importe quelle taille et performances.
- Distribuez les versions à tout le monde et vivez avec une expérience de débogage légèrement altérée.
- Optez pour une politique de distribution vraiment compliquée, fournissant potentiellement des packages de version et de débogage séparés.
Les deux premiers se résument vraiment à l'effet des différences entre les versions de débogage et de version ... bien qu'il soit intéressant de noter qu'il y a aussi une grande différence entre vouloir entrer dans le code d'une bibliothèque parce que vous voulez vérifier certains comportements, et vouloir pour déboguer le code d'une bibliothèque car vous pensez avoir trouvé un bogue. Dans le second cas, il est probablement préférable d'obtenir le code de la bibliothèque en tant que solution Visual Studio et de déboguer de cette façon, donc je ne paie pas trop attention à cette situation.
Ma tentation est de simplement continuer avec les versions, avec l'espoir que relativement peu de gens auront besoin de déboguer, et ceux qui ne le seront pas impacté beaucoup par les optimisations de la version. (Le compilateur JIT fait la plupart des optimisations de toute façon.)
Alors, y a-t-il d'autres options que nous n'avions pas envisagées? Y a-t-il d'autres considérations qui font pencher la balance? Pousser les packages NuGet vers SymbolSource est-il suffisamment nouveau pour que la "meilleure pratique" n'ait pas vraiment été établie?
Au nom de SymbolSource, je pense que la meilleure pratique consiste à:
- Transférer les packages binaires + de contenu vers nuget.org uniquement (ou tout autre flux de production)
- Envoyez les packages de contenu binaire + de débogage à un flux de développement:
- sur site
- sur myget.org
- sur nuget.org en tant que packages de pré-version.
- Poussez à la fois les packages de symboles binaires + de débogage vers symbolesource.org ou tout autre magasin de symboles.
Pendant que nous y sommes, c'est une idée fausse courante que les versions de version et de débogage dans .NET diffèrent vraiment beaucoup, mais je suppose que la différenciation est ici en raison de divers codes qui pourraient ou non être inclus dans l'une ou l'autre version, comme Debug .Assert.
Cela dit, il vaut vraiment la peine de pousser les deux configurations vers SymbolSource, car vous ne savez jamais quand vous devrez déboguer le code de production. À distance en production pour le rendre plus difficile. Vous aurez besoin de l'aide que vous pourrez obtenir de votre outillage lorsque cela se produira. Ce que je ne souhaite évidemment à personne.
Il y a encore une question à considérer concernant le versioning: est-il correct d'avoir 2 packages différents (build en debug et en release) partageant 1 numéro de version? SymbolSource accepterait cela, car il extrait les packages et stocke les binaires dans des branches de mode de construction distinctes, SI SEULEMENT NuGet est autorisé à baliser les packages en conséquence. Il n'existe actuellement aucun moyen de déterminer si un package est en mode debug ou release.
Je suis entièrement d'accord avec votre conclusion. Packages NuGet avec RELEASE et SymbolSource avec débogage. Il semble assez rare d'entrer directement dans les packages et le faux-débogage occasionnel avec les optimisations activées peut être acceptable.
S'il y avait vraiment un problème, je pense que la solution idéale serait que NuGet le prenne en charge. Par exemple, imaginez si lors du débogage, il pourrait remplacer la version DLL par celle incluse dans le package SymbolSource.
Idéalement, ce qui se passerait alors, c'est que nuget pack SomePackage -Symbols par rapport à une version finale créerait un paquetage de nuget de sortie, mais un paquet de symboles de débogage. Et le plugin VS serait mis à jour pour être suffisamment intelligent pour voir l'association et extraire les assemblys de débogage lors de l'exécution dans un débogueur et les charger à la place. Un peu fou, mais ce serait intéressant.
Cependant, je ne vois tout simplement pas assez de gens se plaindre de cela que cela en vaut la peine pour le moment.
L'équipe NuGet accepte les demandes de tirage. :)
L'exemple dans Création et publication d'un package de symboles fait référence aux fichiers des répertoires de débogage comme sources pour les fichiers dll et pdb.
Spécification du contenu du package de symboles
Un package de symboles peut être construit par des conventions, à partir d'un dossier structuré de la manière décrite dans la section précédente, ou son contenu peut être spécifié à l'aide de la section fichiers. Si vous vouliez construire l'exemple de package décrit précédemment, vous pouvez le mettre dans votre fichier nuspec:
<files>
<file src="Full\bin\Debug\*.dll" target="lib\net40" />
<file src="Full\bin\Debug\*.pdb" target="lib\net40" />
<file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" />
<file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" />
<file src="**\*.cs" target="src" />
</files>
Étant donné que le but de la publication des symboles est de permettre aux autres de parcourir votre code lors du débogage, il semble plus prudent de publier une version du code destinée au débogage sans optimisations qui pourraient affecter le code pas à pas.