Erreur WCF - élément de détail manquant

Question

Nous avons un comportement de gestion des exceptions personnalisées (implémentation de IErrorHandler) dans notre solution qui utilise essentiellement Automapper pour convertir les exceptions en défauts. Cela fonctionne bien depuis le jour 1. Cependant, nous venons tout juste de remarquer lors de la consultation de ServiceTraceViewer (en regardant les journaux du serveur - pas client) sur notre serveur de développement partagé que les erreurs renvoyées par nos services omettent l'élément detail. En exécutant exactement le même code et la même configuration sur ma machine de développement, l'élément de détail est correctement renseigné. Comme je le dis, les fichiers de configuration (comportements, bindings) sont identiques sur les deux machines. Les deux configurations spécifient includeExceptiondetailsInFaults = true.

J'ai aussi ajouté un tas de déclarations de journaux qui semblent indiquer que le même chemin de code est suivi sur les deux machines avec les mêmes valeurs pour différentes choses comme code de défaut, la raison de défaut, etc.

Ma machine dev est la norme 2008R2 (64bit). Le serveur en question est également 2008R2 Standard (64 bits).

Je peux poster des extraits du code si nécessaire, mais dans le premier cas, y at-il quelque chose d'environnemental qui pourrait permettre ce que nous voyons?

Extrait du fichier de problème:

<s:Body u:Id="_1"> 
<s:Fault> 
<s:Code> 
<s:Value>s:Sender</s:Value> 
</s:Code> 
<s:Reason> 
<s:Text xml:lang="en-NZ">An error occured during the request to the ...</s:Text> 
</s:Reason> 
</s:Fault> 
</s:Body> 

Answer 1

pas à 100% sûr de l'étiquette ici. C'est une réponse que je devine à ma marque de bêtise spécifique. Peut-être que quelqu'un d'autre sera aussi stupide, alors la réponse s'applique à eux ...

J'étais sûr d'avoir tout comparé (j'ai indiqué exactement le même code/configuration). Mais le fichier de configuration du comportement que je viens de donner un visuel rapide. Après qu'un autre développeur m'ait approché, j'ai réalisé que les fichiers locaux n'étaient PAS les mêmes que les fichiers du serveur. Doh!

En fait, les fichiers du serveur ont une ligne supplémentaire ajoutée par une étape de post de construction - déclencher un autre comportement personnalisé qui mettait en œuvre IErrorHandler en plus du comportement IErrorHandler que nous utilisons déjà pour l'exploitation forestière, etc.

Je suppose que je vais ouvrir une autre question maintenant qui cherche une réponse à l'approche consistant à avoir plusieurs comportements mettant en œuvre la même interface et ne pas polluer les autres fonctionnalités (comme retourner des fautes).