Discussion :

[imad_eddine]

Bonjour,

Lors de la compilation d'une solution en VS, y a deux mode Debug et Release.
J'aimerais savoir la différence entre les deux..

Merci d'avance

------------------------------------
Imad-Eddine

[SaumonAgile]

Il te suffit de regarder dans les propriétés (section 'Build') de ton projet dans VS, tu vois les différences de configuration du compilateur quand tu passes de Debug à Release et inversement.

[Jérôme Lambert]

Le mode Debug te permet de... débuguer, c'est à dire d'utiliser des breakpoint, etc... Ce mode est donc utilisé durant le développement.

Quand ton application est finie et que tu comptes la passer en testes, voir production, tu passes au mode release, dans ce cas, il n'est plus possible de faire du debugging car suppression des symbole pour le mode debug, le code compilé est optimisé etc. Comme l'a dit SaumonAgile, ce sont des propriétés qui sont visibles et modifiables via Visual Studio.

[imad_eddine]

OK, OK... Je vois
Merci les amis.

--------------------------------------------------
Imad-Eddine

[kfx_2000]

Bonjour,
Et concernant le code compilé entre le mode debug et release : est-ce qu'il y a des grosses différences concernant :
- la consommation mémoire
- la rapidité d'éxécution
- la taille de l'éxécutable
- etc

D'autres part, les systèmes de log (ex nlog) permettent-ils de remonter des stacktraces aussi complètes (appel de méthodes respectives avec n°ligne...) afin de diagnostiquer rapidement un bug ?

En fait, j'ai pris la mauvaise habitude (qui risque de changer selon vos réponses) de délivrer l'éxécutable compilé en mode debug avec son fichier pdb associé car mon application pas besoin de beaucoup de perf. et je préfère un programme moins rapide mais plus facilement debuggable. Est-ce vraiment "préjudiciable" de faire ainsi ?

[Louis-Guillaume Morand]

nana jamais livrer en debug.
le mod debug rajoute ce qu'on appelle des symboles qui permettent pour les breakpoint, et aussi simplement pour renvoyer à la bonne ligne de code en debug. niveau perf, c'est moins performant une appli en mode debug maintenant les banchs se contredisent, certains parlent de moins de 5% de diff tandis que d'autres annoncent au moins 10% de diff.

D'autres part, les systèmes de log (ex nlog) permettent-ils de remonter des stacktraces aussi complètes (appel de méthodes respectives avec n°ligne...) afin de diagnostiquer rapidement un bug ?

bien sûr, ils sont fait pour. faut juste les configurer correctement.

et je préfère un programme moins rapide mais plus facilement debuggable

tu ne debug pas un programme déployé donc le mode debug sert à rien. le debug se fait sur le poste de developpeur et sur les postes deployés, c'est par l'analyse des logs qu'on trouve un bug.

la meilleure solution reste encore de faire un programme sans bugs

[SaumonAgile]

nana jamais livrer en debug.
le mod debug rajoute ce qu'on appelle des symboles qui permettent pour les breakpoint, et aussi simplement pour renvoyer à la bonne ligne de code en debug. niveau perf, c'est moins performant une appli en mode debug maintenant les banchs se contredisent, certains parlent de moins de 5% de diff tandis que d'autres annoncent au moins 10% de diff.

A ma connaissance, le mode debug n'ajoute pas de symboles de débogage, les informations de debug sont fournies par les fichiers pdb. Si tu ne fournis pas le pdb, les assembly ne diffèrent que de quelques optimisations (configurables). C'est d'ailleurs pour ça que tu peux déboguer le framework sans rien changer, c'est simplement VS qui charge le pdb qui va avec l'assembly depuis les serveurs Microsoft.

Mais comme dit, c'est "à ma connaissance".

[Louis-Guillaume Morand]

nope. suffit de comparer la taille d'un executable entre debug et release, normalement, y a tjs une bonne vingtaine de ko de différence même sur un fichier de taille minime.
effectivement, un set complet de symboles sont ajoutés au fichiers pdb mais le code lui même ne sera pas le meme. le pdb ne sert qu'au mapping avec Visual Studio justement comme tu le disais
tout d'abord à cause des prédicats (IF DEBUG par exemple) mais aussi à cause de certains flags qui vont optimiser la génération du code final (voir le flag IsJitOptimizerEnabled)
http://msdn.microsoft.com/en-us/libr...attribute.aspx

maintenant, c'est vrai que cette différence est sûrement la chose la moins documentée des trucs microsoft

[kfx_2000]

Merci pour ces eclaircissements Louis-Guillaume ! Je vais donc utiliser ces 2 modes de compilation.

Par contre concernant les fichiers PDB, à priori : ils ne faut pas les déployer (vraiment ?).
Mais sans ces fichiers, les numéros de lignes n'apparraissent pas dans les stacktraces des logs de log4net, du coup ça peut-être quelques fois génant pour trouver d'où vient le problème.

D'ailleurs, je ne comprends pas pourquoi Visual Studio génère ces fichiers par défaut en mode release si il ne faut pas les déployer (CF ProjectProperties/Build/Advanced/Debug Info positionné à pdb-only).

[Louis-Guillaume Morand]

http://gchandra.wordpress.com/2008/0...-release-mode/
sinon, c'est sûr il faut pas les déployer. quant à la ligne de code, il me semblait qu'on pouvait le trouver via l'objet Source d'une exception (à vérifier).


Pour le reste, normalement la trace te donne la méthode or une méthode est rarement très longue donc ca réduit le debugging.