Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Installation appli en debug ou release

Installation appli en debug ou release

12 réponses
Avatar
Sylvain MALLEVAL
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en release,
j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Frédéric Queudret [MS]
Bonjour,

La version debug est essentiellement utile pour débuggé d'où son nom
(exécution pas à pas,etc.).
Pour remonter un maximum d'informations, notamment sur une exception,
utilisez StackTrace qui vous fournira beaucoup d'infos.
(exemple StackTrace.ToString() vous affichera la pile des appels)
Cordialement,
Frédéric.

"Sylvain MALLEVAL" <devbnet@[antispam]free.fr> wrote in message
news:
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en
release, j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain



Avatar
Sylvain MALLEVAL
Donc si je comprend bien, il n'y a aucun intérêt a installé une application
en debug, les messages d'erreur seront le mêmes ????
Merci
Sylvain

"Frédéric Queudret [MS]" a écrit dans le
message de news:
Bonjour,

La version debug est essentiellement utile pour débuggé d'où son nom
(exécution pas à pas,etc.).
Pour remonter un maximum d'informations, notamment sur une exception,
utilisez StackTrace qui vous fournira beaucoup d'infos.
(exemple StackTrace.ToString() vous affichera la pile des appels)
Cordialement,
Frédéric.

"Sylvain MALLEVAL" <devbnet@[antispam]free.fr> wrote in message
news:
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en
release, j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain







Avatar
Frédéric Queudret [MS]
Le déploiement en mode debug est limité si vous n'attachez pas de debugger
ou que vous ne capturez pas les sorties Debug.
Voici la doc MSDN (en anglais) sur ce point:
Code Tracing and Debugging
During development, you can use the output methods of the Debug class to
display messages in the Output window of the Visual Studio integrated
development environment (IDE). For example:

' Visual Basic
Trace.WriteLine("Hello World!")
Debug.WriteLine("Hello World!")

// C#
System.Diagnostics.Trace.WriteLine("Hello World!");
System.Diagnostics.Debug.WriteLine("Hello World!");Each of these examples
will display "Hello World!" in the Output window when the application is run
in the debugger.

This enables you to debug your applications and optimize their performance
based on their behavior in your test environment. You can debug your
application in your debug build with the Debug conditional attribute turned
on so that you receive all debugging output. When your application is ready
for release, you can compile your release build without turning on the Debug
conditional attribute, so that the compiler will not include your debugging
code in the final executable.

You can also trace code execution in an installed application, using methods
of the Trace class. By placing Trace Switches in your code, you can control
whether tracing occurs and how extensive it is. This lets you monitor the
status of your application in a production environment. This is especially
important in a business application that uses multiple components running on
multiple computers. You can control how the switches are used after
deployment through the configuration file.

When you are developing an application for which you intend to use tracing,
you usually include both tracing and debugging messages in the application
code. When you are ready to deploy the application, you can compile your
release build without turning on the Debug conditional attribute. However,
you can turn on the Trace conditional attribute so that the compiler
includes your trace code in the executable.

C'est pour cela qu'il est important de bien comprendre la différence entre
Trace et Debug (et d'autres notions telles que Audit, Instrumentation via
les compteurs de performance, etc.).
Debug est vraiment prévu pour debugger le code pendant la phase de
développement avant le passage à une version Release optimisée à la
compilation et déployable.

Frédéric.

"Sylvain MALLEVAL" <devbnet@[antispam]free.fr> wrote in message
news:
Donc si je comprend bien, il n'y a aucun intérêt a installé une
application en debug, les messages d'erreur seront le mêmes ????
Merci
Sylvain

"Frédéric Queudret [MS]" a écrit dans le
message de news:
Bonjour,

La version debug est essentiellement utile pour débuggé d'où son nom
(exécution pas à pas,etc.).
Pour remonter un maximum d'informations, notamment sur une exception,
utilisez StackTrace qui vous fournira beaucoup d'infos.
(exemple StackTrace.ToString() vous affichera la pile des appels)
Cordialement,
Frédéric.

"Sylvain MALLEVAL" <devbnet@[antispam]free.fr> wrote in message
news:
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en
release, j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain











Avatar
Olivier Huet
Bonjour,


En plus de ce qui a déjà été dit dans les autres messages, pour avoir
les numéros de lignes dans les commandes comme StackTrace.ToString, il
faut livrer aussi les fichiers .pdb (générés à côté de l'application)
contenant des informations de debug.

Ils sont aussi générable en Release en cochant la case ad-hoc dans VS
(generate debug informations, ou quelque-chose du genre).


Olivier Huet



Sylvain MALLEVAL a écrit :
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en release,
j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain




Avatar
Sylvain MALLEVAL
c'est cela dont j'ai besoin...
Peut tu me donner plus de précision sur comment livrer les fichiers .pdb en
release et quelle case cocher ???

Merci

"Olivier Huet" a écrit dans le message
de news:
Bonjour,


En plus de ce qui a déjà été dit dans les autres messages, pour avoir les
numéros de lignes dans les commandes comme StackTrace.ToString, il faut
livrer aussi les fichiers .pdb (générés à côté de l'application) contenant
des informations de debug.

Ils sont aussi générable en Release en cochant la case ad-hoc dans VS
(generate debug informations, ou quelque-chose du genre).


Olivier Huet



Sylvain MALLEVAL a écrit :
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en
release, j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain




Avatar
Sylvain MALLEVAL
C bon, g trouvé, c kool, merci
Sylvain
"Olivier Huet" a écrit dans le message
de news:
Bonjour,


En plus de ce qui a déjà été dit dans les autres messages, pour avoir les
numéros de lignes dans les commandes comme StackTrace.ToString, il faut
livrer aussi les fichiers .pdb (générés à côté de l'application) contenant
des informations de debug.

Ils sont aussi générable en Release en cochant la case ad-hoc dans VS
(generate debug informations, ou quelque-chose du genre).


Olivier Huet



Sylvain MALLEVAL a écrit :
Salut,

Je pensais qu'en installant mon, application en debug plutôt qu'en
release, j'aurais eu des messages des erreurs plus explicite
avec les numéros de ligne, etc...
Mais ce n'est pas le cas...
Est ce normal, y a t'il une option qu'il faut activer...

Merci

Sylvain




Avatar
Arnaud Debaene
Sylvain MALLEVAL wrote:
c'est cela dont j'ai besoin...
Peut tu me donner plus de précision sur comment livrer les fichiers
.pdb en release et quelle case cocher ???


Ah? Tu veux livrer tes pdb? Ce n'est pas courant : soit tu livres les
sources à ton client (et dans ce cas il peux regénérer les pdb s'il veut),
soit tu lui fournit juste le binaire, et dans ce cas tu ne veux généralement
pas que le client mette son nez dans ton code source (propriété
intellectuelle et toutes sortes d'autres raisons). Dans ce 2nd cas, lui
fournir les pdb, c'est lui faciliter énormément la tache s'il veux
désassembler et comprendre ton programme. Donc c'est assez curieux comme
besoin...

Arnaud
MVP - VC
Avatar
Olivier Huet
Bonjour,


Arnaud Debaene a écrit :
Ah? Tu veux livrer tes pdb? Ce n'est pas courant :
...




En même temps, le besoin de Sylvain est d'avoir les numéros de lignes
dans les piles d'exceptions : c'est à ma connaissance la seule manière
de répondre à ce besoin : en connais-tu une autre ?


Et livrer les .pdb, si c'est pour un client chez qui ça plante ou sur un
serveur, après tout pourquoi pas ? Dans le temps, sur du code C++ qui
avait été un peu "salopé", on faisait ça pour avoir la version .log de
Dr Watson (drwtsn32.log) contenant les symboles précis et les numéros de
lignes etc. C'était parfois plus pratique que de se trimbaler le .dmp.


Olivier Huet
Avatar
Arnaud Debaene
Olivier Huet wrote:
Ah? Tu veux livrer tes pdb? Ce n'est pas courant :



En même temps, le besoin de Sylvain est d'avoir les numéros de lignes
dans les piles d'exceptions : c'est à ma connaissance la seule manière
de répondre à ce besoin : en connais-tu une autre ?


La "bonne" solution est de générer un dump que le développeur récupère pour
pouvoir l'analyser ensuite. Si on livre le symboles, il faut être conscient
que ca revient pour ainsi dire de livrer les sources (ce qui peut être un
problème ou pas, c'est un autre débat)..

Et livrer les .pdb, si c'est pour un client chez qui ça plante ou sur
un serveur, après tout pourquoi pas ? Dans le temps, sur du code C++
qui avait été un peu "salopé", on faisait ça pour avoir la version
.log de Dr Watson (drwtsn32.log) contenant les symboles précis et les
numéros de lignes etc. C'était parfois plus pratique que de se
trimbaler le .dmp.


Dr Watson ou tout autre debugger post-mortem (cdb en utilisant ADPlus est
probablement le plus puissant) peuvent parfaitement générer des dumps
complets sans que les symboles soient disponibles. Ensuite, on doit disposer
des symboles pour analyser au mieux ces dumps, mais il ne sont pas
nécessaires sur la machine où le dump est réalisé. Cette technique est
encore utilisable en .NET d'ailleurs (grâce à l'extension sos.dll des
debuggers Système qui permet de travailler sur du code managé).

Pour livrer un soft "propriétaire" (sans livrer les sources), le mieux est
de le compiler en release mais en générant les pdb. On livre alors les
binaires et on garde soigneusement dans un coin les pdb pour qu'ils puissent
être utilisés pour du debogage post-mortem si nécessaire. Le serveur de
symboles qui vient avec le outils de debugging
(http://www.microsoft.com/whdc/devtools/debugging/default.mspx) est parfait
pour conserver ces pdb.

Arnaud
MVP - VC
Avatar
Olivier Huet
Bonjour,


Arnaud Debaene a écrit :
La "bonne" solution est de générer un dump que le développeur récupère pour
pouvoir l'analyser ensuite.



oui pardon, je voulais dire "quelque-chose de copier/collable dans un
mail, par exemple", sinon en effet, un minidump est plus pratique. Le
problème est quand il est gros et que le client a une ligne moyennement
rapide...

Sinon, effectivement, la technique que tu indique est plus puissante,
mais elle est surtout utile pour du code "non managé", ou un mix entre
du code natif et du code "managé".

->elle me semble donc assez peu conseillable par rapport à la question
de Sylvain : l'analyse de dump, bien qu'amusante ( oui, je m'amuse d'un
rien :-) ), est plutôt à faire si on ne peut pas faire autrement.


Si on livre le symboles, il faut être conscient
que ca revient pour ainsi dire de livrer les sources (ce qui peut être un
problème ou pas, c'est un autre débat)..



En même temps, en livrant un exécutable .Net, on livre quelque-chose de
déjà très facilement analysable (mais là aussi, c'est un autre débat).


Olivier Huet
1 2