Les meilleures pratiques avec Nuget: Debug ou Release?

Question

Actuellement, j'ai package de la release avec Nuget, pour le fonctionnaire s'appuie à nuget.org mais je package les versions de débogage avec Nuget pour la source de symbole pousse à symbolsource.org.

EDIT: (Jon Skeet, avec un certain penchant de Noda Temps de développement)

NuGet prend désormais en charge les poussant à la fois galerie NuGet et symbolsource.org (ou similaire serveurs), comme indiqué. Malheureusement, il y a deux exigences contradictoires ici:

• Quand il vient à l'aide d' une bibliothèque sans qu'il soit besoin pour le débogage, vous voulez vraiment un communiqué de construire. C'est ce que les versions release, après tout.
• Lors du débogage d'une bibliothèque à des fins de diagnostic, vous voulez vraiment d'une version de débogage avec toutes les optimisations désactivé. C'est ce que les versions de débogage sont, après tout.

Ce serait bien, mais NuGet n'est pas (pour autant que je puisse dire) permettent à la fois la release et debug pour être publié dans une manière utile, dans le même package.

Ainsi, les choix sont les suivants:

• Distribuer les versions de débogage pour tout le monde (comme le montre l'exemple de la doc) et de vivre avec n'importe quelle taille et les performances.
• Distribuer les versions release pour tout le monde et de vivre avec une légère altération de débogage de l'expérience.
• Aller pour une vraiment compliqué politique de distribution, fournissant potentiellement un communiqué de presse distinct et les paquets de débogage.

Les deux premiers vraiment se résument à l'effet des différences entre debug et release... mais il est intéressant de noter qu'il existe aussi une grande différence entre vouloir étape dans le code d'une bibliothèque parce que vous voulez vérifier certains comportements, et de vouloir pour déboguer le code d'une bibliothèque parce que vous croyez que vous avez trouvé un bug. Dans le second cas, c'est probablement mieux pour obtenir le code de la bibliothèque comme une solution Visual Studio et de débogage de cette façon, donc je ne vais pas payer trop d'attention à cette situation.

Ma tentation est de continuer avec la release, avec l'espoir que relativement peu de personnes auront besoin de déboguer, et ceux qui le font ne seront pas touchées beaucoup par les optimisations dans la version release. (Le compilateur JIT n'est plus de l'optimisation de toute façon.)

Donc, existe-il d'autres options que nous n'avions pas pris en compte? Existe-il d'autres considérations qui font pencher la balance? Est de pousser les packages NuGet à SymbolSource suffisamment de nouvelles que les "meilleures pratiques" n'a pas vraiment été mis en place?

Answer 1

En parlant de SymbolSource, je crois que la meilleure pratique consiste à:

1. Pousser version binaire+contenu des paquets à nuget.org uniquement (ou de toute autre production d'alimentation)
2. Pousser debug binaire+contenu des paquets d'un flux de développement:
   • sur site
   • sur myget.org
   • sur nuget.org comme pré-version des paquets.
3. Poussez les deux release et debug binaire+symboles de paquets symbolsource.org ou tout autre symbole magasin.

Pendant que nous y sommes, c'est une idée fausse commune que la release et debug .NET vraiment diffèrent beaucoup, mais je suis en supposant que la différenciation est ici à cause de divers code qui pourrait ou ne pourrait pas être inclus dans la construction, à l'instar de Débogage.L'affirme.

Cela dit, il est vraiment la peine de pousser les deux configurations pour SymbolSource, parce que vous ne savez jamais quand vous allez avoir besoin de déboguer le code de production. À distance de la production pour le rendre plus dur. Vous allez avoir besoin de l'aide que vous pouvez obtenir auprès de votre outillage lorsque cela se produit. Ce qui évidemment je ne souhaite à personne.

Il y a encore une question à prendre en compte concernant les versions: est-il correct d'avoir 2 paquets différents (construire en debug et en release) partage 1 numéro de version? SymbolSource accepterait, car il extrait les paquets et les stocke les fichiers binaires en séparer le mode de construction des branches, SI SEULEMENT NuGet permis de baliser les paquets en conséquence. Il n'existe aucun moyen à l'heure actuelle pour déterminer si un paquet est debug ou release-mode.

Answer 2

Je suis entièrement d'accord avec votre conclusion. Les packages NuGet avec la LIBÉRATION et la SymbolSource avec debug. Il semble assez rare à l'étape directement dans des packages et à l'occasion de débogage faux pas avec les optimisations activées peut être acceptable.

Si il y avait vraiment un problème, je pense que la solution idéale serait d'avoir NuGet le soutenir. Imaginez, par exemple, si lors du débogage, il pourrait remplacer la version de la DLL avec celui inclus dans le SymbolSource paquet.

Idéalement, qu'arriverait-il alors est-ce que nuget pack SomePackage -Symbols contre une version permettrait de créer une version de package nuget, mais un des symboles de débogage paquet. Et VS plugin serait mis à jour pour être assez intelligent pour voir l'association et tirez dans le Débogage assemblées lors de l'exécution dans un débogueur et de la charge à la place. Un peu fou, mais ce serait intéressant.

Cependant, je ne vois tout simplement pas assez de gens se plaindre de ce que ça en vaut la peine pour le moment.

NuGet équipe accepte pull requests. :)

Answer 3

L'exemple de la Création et de la Publication d'Un Paquet de Symbole références des fichiers dans le Débogage des répertoires des sources d'information pour les dll et les fichiers pdb.

La Spécification Du Symbole Contenu De L'Emballage

Un paquet de symbole peut être construit par les conventions, à partir d'un dossier structuré de la manière décrite dans la section précédente, ou de son contenu peut être spécifié à l'aide de la section fichiers. Si vous voulez construire l'exemple de package décrit précédemment, vous pouvez mettre ceci 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>

Depuis la publication de la signification des symboles est de permettre à d'autres de l'étape par le biais de votre code lors du débogage, il semble plus prudent de publier une version du code destiné à des fins de débogage sans optimisations qui pourraient affecter le code pas à travers.