Discussion :

[Lucas Panny]

Bonjour,

Je teste toujours sous Debug et maintenant que je dois livrer l'application, il faut générer une version Release (n'est-ce pas?)

Il y a aussi que j'utilise "WPF Themes" pour mon thème et le soucis avec ce dernier c'est qu'il faut WPFToolkit.dll dans WPF.Themes\bin\Debug pour que ça s'utilise, je mets aussi ce dll dans WPF.Themes\bin\Release.

Je génère en Release, ça passe mais rien n'est créé dans bin\Release du projet principal, pourquoi?

[ostenhard]

Bonjour,

Il faut vérifier que la configuration Release génére bien tous les projets.
Puis ensuite tu peux vérifier quel est le répertoire de sortie en release de ton projet dans ses propriétés.

[Lucas Panny]

Je viens de regarder Projects>Properties>Onglet Compile, je vois en effet que c'est bin\Debug, je change en bin\Release
Mais pourquoi ce n'est plus automatique comme avant (VS2003 et VS2005)?

Un message d'alerte s'affiche par contre:

The following module was built either with optimizations enabled or without debug information:
D:\.......\CustomColorPicker.dll

Par curiosité, les fichiers .pdb sont-ils nécessaires à la livraison pour que l'application marche?

[Arnard]

les fichiers pdb sont des fichiers dédiés au debug, ils n'ont pas lieu d'être fournis au client.

[Bluedeep]

Par curiosité, les fichiers .pdb sont-ils nécessaires à la livraison pour que l'application marche?

Non, pas du tout, mais ils permettent, si tu as, par exemple un framework de trace, d'avoir en cas de plante la ligne où une exception se produit (ce qui peut être commode).

[Bluedeep]

les fichiers pdb sont des fichiers dédiés au debug, ils n'ont pas lieu d'être fournis au client.

Pas tout à fait exact. cf. ma remarque supra.

[ostenhard]

Pas tout à fait exact. cf. ma remarque supra.

Personnellement, je dirai que les pdb n'ont rien à faire en Prod, mais peuvent être fournis (et je le conseille) aux clients pour les tests en phase d'intégration et de qualif'.

En effet les pdb donnent des informations supplémentaires lorsque des erreurs surviennent, mais selon moi en donne trop sur un environnement où l'application est sensée fonctionner sans accrocs.

[Bluedeep]

Personnellement, je dirai que les pdb n'ont rien à faire en Prod, mais peuvent être fournis (et je le conseille) aux clients pour les tests en phase d'intégration et de qualif'.

En effet les pdb donnent des informations supplémentaires lorsque des erreurs surviennent, mais selon moi en donne trop sur un environnement où l'application est sensée fonctionner sans accrocs.

Je ne suis pas d'accord.
L'application est en effet peut être "sensée fonctionner" sans accrocs.

Néanmoins je n'ai jamais vu une phase de recette capable de mettre en évidence la totalité des problèmes (je parle sur une chaine applicative "sérieuse", je ne parles pas d'un module de 5000 ou 10000 lignes de code).

Même après une phase de pre-prod, on découvre encore des problèmes tout simplement par ce que en passant de, disons, 100 utilisateurs à 2000, des possibilités de manips invalides qu'on aurait absolument jamais imaginées apparaissent grace à la miraculeuse imagination des utilisteurs.

Sans même parler des invalidités possibles des données échangées avec les applications tiers du SI : on croit avoir prévu toutes les invalidités d'entrées possibles, mais non .... (ou alors tu es vraiment un grand génie de l'IT et je m'incline).

Par conséquent, j'estime avoir besoin des retours de prod en cas d'incident, et en l'occurence le numéro des lignes où sont levées les exceptions le cas échéant. (bien sur ma remarque n'a de sens qui si tu disposes d'une instrulentation sérieuse sous la forme d'un framework de traces ou autre - dans le cas contraire, je t'accorde que cela ne sert à rien).

Bien entendu, si tu travailles pour un éditeur, tu peux avoir une vision un peu différente de la vision SI interne (mais pour avoir été chef de produits pendant longtemps chez un éditeur,j'ai les deux visions )

[Arnard]

L'impossibilité de rencontrer tous les soucis, ça ok. Par contre on peut relativiser la livraison des pdb selon si le produit développé est spécifique à un client ou global...

Je sais que le pdb documente bien la dll (vu qu'on a les lignes), mais on peut gagner quoi comme infos précisément ?

[Bluedeep]

L'impossibilité de rencontrer tous les soucis, ça ok. Par contre on peut relativiser la livraison des pdb selon si le produit développé est spécifique à un client ou global...

Je sais que le pdb documente bien la dll (vu qu'on a les lignes), mais on peut gagner quoi comme infos précisément ?

Pour ma part, le seul usage réel que je fais des pdb est la possibilité de capter le numéro de ligne d'une exception levée, puisque tout le reste je peux le capturer à partir du contexte de l'exception (et on centralise tout cela dans une base d'instrumentation commune à toutes les applications. C'est un framework de trace que nous avons développé en utilisant PostSharp et le Logger de l'EL 4.1 de Microsoft).

[ostenhard]

Je ne suis pas d'accord.
L'application est en effet peut être "sensée fonctionner" sans accrocs.

Néanmoins je n'ai jamais vu une phase de recette capable de mettre en évidence la totalité des problèmes (je parle sur une chaine applicative "sérieuse", je ne parles pas d'un module de 5000 ou 10000 lignes de code).

Même après une phase de pre-prod, on découvre encore des problèmes tout simplement par ce que en passant de, disons, 100 utilisateurs à 2000, des possibilités de manips invalides qu'on aurait absolument jamais imaginées apparaissent grace à la miraculeuse imagination des utilisteurs.

Sans même parler des invalidités possibles des données échangées avec les applications tiers du SI : on croit avoir prévu toutes les invalidités d'entrées possibles, mais non .... (ou alors tu es vraiment un grand génie de l'IT et je m'incline).

Par conséquent, j'estime avoir besoin des retours de prod en cas d'incident, et en l'occurence le numéro des lignes où sont levées les exceptions le cas échéant. (bien sur ma remarque n'a de sens qui si tu disposes d'une instrulentation sérieuse sous la forme d'un framework de traces ou autre - dans le cas contraire, je t'accorde que cela ne sert à rien).

Bien entendu, si tu travailles pour un éditeur, tu peux avoir une vision un peu différente de la vision SI interne (mais pour avoir été chef de produits pendant longtemps chez un éditeur,j'ai les deux visions )

Je comprends totalement ta vision, sinon non je n'ai jamais bossé chez un éditeur, je n'ai fait que de l'intégration et du développement de logiciels spécifiques ou de progiciels.

C'est vrai qu'avoir l'indication de la ligne sur laquelle l'erreur s'est produite est un gage de rapidité d'analyse.

En fait la question serait plutôt : ok avoir cette info c'est génial mais en fait quel est son coût ? les contre ?

Tout le reste peut être de pur dialogues stériles (attention, je pense que ton avis selon tes explications est justifié).

Maintenant, disons pour une application (je réduis je sais) développer selon toutes les règles (applicables) de l'art (en gros je pense, correctement factoriser, respect des couches, faible complexité du code, trace parlante (pas juste un message d'erreur) contenant le nom de la méthode, ...=> cf PostSharp et autres), la présence des pdb si elle a un coût n'est-elle simplement pas inutile ? ou d'une utilité très réduite et maîtrisée ?

Alors je sais une telle application c'est vraiment rare (car il faut faire avec l'humain et c'est pas toujours le meilleur quand on parle de programmation), j'ai vu des applications (pas des petites disons en moyenne 10 développeurs tous les jours sur deux ans c'est pas petit) bien commencer pour finir...