Meilleures pratiques avec Nuget: débogage ou publication?

89

Actuellement, j'emballe les builds de version avec Nuget pour les builds officiels sur nuget.org, mais je package les builds de débogage avec Nuget pour les poussées de source de symbole vers Symbolsource.org.

EDIT: (Jon Skeet, avec un parti pris du développement de Noda Time)

NuGet prend désormais en charge le transfert vers la galerie NuGet et Symbolsource.org (ou des serveurs similaires), comme indiqué . Malheureusement, il y a deux exigences contradictoires ici:

  • Lorsque vous utilisez simplement une bibliothèque sans aucun débogage, vous voulez vraiment une version de 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 builds de débogage, après tout.

Ce serait bien, mais NuGet ne permet pas (pour autant que je sache) que les versions de version et de débogage soient publiées de manière utile, dans le même package.

Ainsi, les choix sont:

  • Distribuez les versions de débogage à tout le monde (comme indiqué dans l'exemple de la documentation) et en direct avec n'importe quelle taille et performances.
  • Distribuez les versions de version à 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 publication ... 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 un comportement et vouloir pour déboguer le code d'une bibliothèque parce que 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 le déboguer de cette façon, donc je ne prête pas trop attention à cette situation.

Ma tentation est de rester avec les versions de version, avec l'espoir que relativement peu de personnes auront besoin de déboguer, et celles qui le feront ne seront pas beaucoup affectées par les optimisations de la version de version. (Le compilateur JIT effectue la plupart de l'optimisation 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? Le transfert de packages NuGet vers SymbolSource est-il suffisamment nouveau pour que les «meilleures pratiques» n'aient pas vraiment été établies?

visual-studio  debugging  release  nuget 
— gzak
source
2
J'étais sur le point de poser la même question - même si actuellement je pousse la configuration Release vers Symbolsource aussi, étant donné que je suis juste en train d'utiliser nuget pack ... -Symbolet de pousser les packages générés ...
— Jon Skeet
1
Je pense que je devrais soumettre cette session de questions / réponses aux gens derrière NuGet et voir s'ils peuvent y peser.
— gzak
Connectez-vous à votre package, puis publiez uniquement la version de version. Vous pouvez autoriser l'injection d'enregistreur, ce qui permettra au consommateur de configurer la journalisation selon ses préférences.
— CShark

Réponses:

29

Parlant pour SymbolSource, je pense que la meilleure pratique consiste à:

  1. Push release binary + content packages to nuget.org uniquement (ou tout autre flux de production)
  2. Poussez les packages de débogage binaire + contenu vers un flux de développement:
    • sur site
    • sur myget.org
    • sur nuget.org en tant que packages de pré-version.
  3. Poussez à la fois les packages de version et de débogage de symboles binaires + 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 des versions, comme Debug .Asserts.

Cela dit, cela vaut vraiment la peine de pousser les deux configurations vers SymbolSource, car vous ne savez jamais quand vous allez avoir besoin de déboguer le code de production. À distance en production pour rendre les choses plus difficiles. Vous allez avoir besoin de l'aide que vous pouvez obtenir de votre outillage lorsque cela se produit. Ce que je ne souhaite évidemment à personne.

Il y a encore une question à considérer concernant le contrôle des versions: 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 UNIQUEMENT NuGet est autorisé à étiqueter les packages en conséquence. Il n'existe actuellement aucun moyen de déterminer si un package est en mode débogage ou en mode version.

— TripleEmcoder
source
La partie «publier deux versions sur NuGet» est la partie la plus délicate. J'ai toujours publié la version Release de Noda Time, au motif que je devais choisir entre les deux. (J'ai un fichier nuspec, plutôt que de le faire uniquement à partir du projet C #.) Vous mentionnez le débogage du code de production comme si c'était beaucoup plus difficile avec seulement une version de version - malgré la partie précédente "ils ne diffèrent pas beaucoup". Je connais les NOP dans les versions de débogage, et évidemment, Debug.Assertetc. - mais pourriez-vous développer (dans votre réponse) les implications lors du débogage? À quel point utilise-t-il une version Release?
— Jon Skeet
Ce que je voulais dire, c'était simplement que vous vouliez avoir des symboles disponibles pour tous les binaires utilisés: s'il y a à la fois des versions de débogage et de publication dans la nature, vous voudrez fournir des symboles pour les deux. Ils n'ont pas besoin de beaucoup différer en termes de code, mais ils différeront dans les sommes de contrôle, ce qui rend le chargement de symboles impossible sans piratage.
— TripleEmcoder
1
Droite. Ma solution possible est de ne publier que les binaires Release, mais je m'inquiète de ce que cela va faire en termes de débogage. Par exemple, le manque de NOP signifie-t-il que vous ne pouvez pas ajouter de points d'arrêt?
— Jon Skeet
Le problème vient plus des optimisations JIT que des optimisations au moment de la construction. Donc, si vous poussez des packages en mode version et recommandez d'utiliser COMPLUS_ZapDisable = 1 lorsque le débogage est nécessaire, ce serait assez bien pour moi. Néanmoins, NuGet devrait autoriser le débogage et la publication d'une manière ou d'une autre.
— TripleEmcoder
Je n'avais aucune idée que symbolsource.org existe. Comme une démangeaison, j'ai eu à plusieurs reprises le besoin de se gratter, je m'en réjouis.
— Remus Rusanu
4

Je suis entièrement d'accord avec votre conclusion. Packages NuGet avec RELEASE et SymbolSource avec debug. Il semble assez rare d'entrer directement dans les packages et un faux pas de 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 DLL de version par celle incluse dans le package SymbolSource.

Dans l'idéal, ce qui se passerait alors, c'est que, par nuget pack SomePackage -Symbolsrapport à une version de publication, créerait un package nuget de version, mais un package de symboles de débogage. Et le plugin VS serait mis à jour pour être suffisamment intelligent pour voir l'association et extraire les assemblys Debug 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 pour que cela en vaille la peine pour le moment.

L'équipe NuGet accepte les demandes d'extraction. :)

— Haacked
source
Je ne suis pas sûr de comprendre votre deuxième phrase - je soupçonne que l'OP (avant de modifier) ​​faisait des poussées manuelles vers SymbolSource pour les versions de débogage. Envisagez-vous des questions importantes si la version APB de la version se termine dans SymbolSource au lieu de la version de débogage? Ou est-ce ce que vous préconisiez, et j'ai simplement mal compris?
— Jon Skeet le
3
"Cependant, je ne vois tout simplement pas assez de gens se plaindre de ça pour que ça en vaudrait la peine pour le moment." Peut-être qu'ils ne se plaignent pas, mais si vous demandez à un échantillon d'utilisateurs ce qu'ils en pensent, je parie que vous constaterez que la plupart des gens admettront un peu de confusion à cette étape particulière (quoi publier sur NuGet.org et SymbolSource .org). Si vous leur demandiez ce qu'ils ont fini par choisir, vous découvrirez probablement qu'il n'y a pas de pratique unique convenue, chacun fait son propre truc.
— gzak
7
Je veux m'en plaindre, où dois-je m'inscrire?
— Alex
Une fois que vous avez des NuGets internes et que vous commencez à les déployer sur un serveur de symboles ... vous allez inévitablement vouloir les déboguer .... et même si vous pouvez parcourir le code, vous vous retrouverez avec "Impossible d'obtenir la valeur du variable locale ou argument ... il a été optimisé ". Comme Phil le mentionne ... SI nuget avait un moyen de charger des dll de débogage en mode débogage et de publier des dll en mode release (à partir de packages nuget), ce serait le nec plus ultra. Jusque-là, nous sommes coincés avec le commutateur de paquet
— Nuget
1
Je suis d'accord, ce serait une belle amélioration du produit.
— htm11h
1

L'exemple présenté dans Création et publication d'un package de symboles fait référence aux fichiers des répertoires de débogage en tant que sources pour les fichiers dll et pdb.

Spécification du contenu du paquet de symboles

Un paquet 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é en utilisant la section des fichiers. Si vous souhaitez créer 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 à d'autres personnes 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 pas de code.

— Tvanfosson
source
Oui, c'est ce que fait l' exemple - mais je préfère ne pas finir avec la possibilité de déboguer outrepassant le désir de la plupart des développeurs d'exécuter simplement la version finale. Le problème est que NuGet n'a pas de moyen de publier à la fois les versions de version et de débogage, pour autant que je sache. (Ce serait également un peu pénible pour moi de publier les deux, car cela signifie créer un autre ensemble de configurations, pour les versions de débogage signées ...)
— Jon Skeet
Ici, nous entrons dans un peu de subjectivité. En règle générale, mon choix pour la "meilleure pratique" serait celui que l'auteur recommande, explicitement ou implicitement, car je présume qu'ils ont plus de perspicacité (ou de contrôle, dans le cas d'hypothèses qui aboutissent à des exemples) que moi. Je pense que les symboles doivent correspondre à la version que j'utilise. Je n'utiliserais généralement pas un package que je pensais devoir déboguer, à moins que la source ne soit publique et que je puisse compiler à partir de zéro si nécessaire, donc l'absence d'une version de débogage packagée n'est pas particulièrement importante.
— tvanfosson
Dans mon cas, si quelqu'un a besoin de déboguer Noda Time parce qu'il pense qu'il y a un bogue dans Noda Time, il serait préférable de télécharger la source (ce qu'ils peuvent faire, bien sûr). Cependant, il est toujours utile de pouvoir entrer dans le code source de Noda Time juste pour voir ce qui se passe. En gros, je pense qu'il y a (au moins) deux scénarios différents pour le débogage, avec des solutions différentes ...
— Jon Skeet
Une chose à laquelle j'aime penser est .NET lui-même: je pense qu'il est prudent de dire que Microsoft publie des versions de version et non des versions de débogage de .NET. Une version de version implique un certain niveau de qualité et de stabilité, donc l'idée est que vous devriez rarement avoir besoin d'entrer dans le code pour diagnostiquer les choses.
— gzak
2
Cependant, c'est aussi une mentalité plutôt «de source fermée». J'ai trouvé que dans le monde open source, on s'attend plus à ce que l'on puisse entrer dans le code des "versions stables" de diverses bibliothèques non pas parce que les choses sont cassées, mais parce que parfois la meilleure documentation est de simplement voir ce qu'est la bibliothèque Faire.
— gzak
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.