Discussion :

[anthyme]

Bonjour,

Il m'arrive souvent d'avoir ce genre d'exception dans mon client WCF en général du a une exception levé du coté du serveur WCF.

Mais hélas les exception qui on lieu sur le serveur ne bloque pas le debugger ...
J'ai bien tenté de m'abonner a l'événement Faulted de mon objet ServerHost et de mettre un point d'arrêt dans la méthode abonnée mais rien n'y fait.

Donc voila si vous avez des techniques mieux "qu'essayer de deviner d'où vient l'exception", je suis tout ouïe

Merci

[SoBaKa]

Bonjour,

Je travaille actuellement sur un service WCF qui travaille avec une application mobile et j'ai eu ce genre de soucis...

- Il y a plusieurs moyens de débugger le serveur, mais celui que je trouve plus explicite au niveau des messages est de mettre un point d'arret sur la méthode "getReply" du proxy qui a été généré, tu peux voir le contenu de la variable "msg" qui est du XML avec le message d'erreur.

- Ou alors, quand tu as l'exception coté client tu peux faire un "view details" et la, tu as une propriété InnerException (je pense que tu trouveras ton problème plus facilement ici pour un TargetInvocationException).


Bonne journée...

[anthyme]

Merci d'avoir poster

Pour la 2 je suis d'accord mais pour la 1 tu parle du proxy généré ? (donc du client ?)

donc cela ne debugge pas réellement le serveur

[SoBaKa]

En fait, dans la variable "msg", tu reçois l'erreur du serveur... ce n'est pas vraiment le débugger mais c'est un des moyens que j'avais trouvé pour savoir ou se situais le problème quand je ne savais plus trop où regarder d'autres...

[Hexba]

Ca ne me paraît pas possible, ni logique, de stopper le service en cours sur un serveur. Ce que tu exécutes en debug c'est ton client. C'est possible si tu utilise le serveur de développement intégré à visual studio 2008. Après le comportement peut légèrement différer de ce que tu peux obtenir sur un service hébergé sur IIS par exemple, mais ça facilite quand même beaucoup le débugage.

Tu peux également activer la trace des évènement pour ton serveur, qui va stocker tout ce qui se passe dans un fichier log (que tu pourras consulter avec l'outil "service trace viewer" fourni par microsoft). Le log de permet d'avoir précisément le détail d'une exception, la consultation du stacktrace te permet de savoir là où elle a lieu.

[anthyme]

Ca ne me paraît pas possible, ni logique, de stopper le service en cours sur un serveur. Ce que tu exécutes en debug c'est ton client. C'est possible si tu utilise le serveur de développement intégré à visual studio 2008. Après le comportement peut légèrement différer de ce que tu peux obtenir sur un service hébergé sur IIS par exemple, mais ça facilite quand même beaucoup le débugage.

JE ne vois pas pourquoi on debuguerai uniquement un client... un serveur a lui aussi besoin d'être développé et donc débugué.
Le problème du débug du serveur WCF est que lorsqu'une exception a lieu en amont de ton propre code (par exemple lors de la serialisation des objets pour l'envoie vers le client) et bien le debugueur ne s'arrête pas dessus car c du "code externe".

Tu peux également activer la trace des évènement pour ton serveur, qui va stocker tout ce qui se passe dans un fichier log (que tu pourras consulter avec l'outil "service trace viewer" fourni par microsoft). Le log de permet d'avoir précisément le détail d'une exception, la consultation du stacktrace te permet de savoir là où elle a lieu.

Tu as un exemple d'implémentation ?