We have a custom exception handling behaviour (implementing IErrorHandler) in our solution which essentially uses Automapper to convert exceptions to faults.
This has been working well since day 1. However we have just noticed while browsing ServiceTraceViewer (looking at server logs – not client) on our shared development server that any faults returned from our services omit the detail element.
Running exactly the same code and configuration on my development machine, the detail element is correctly populated. As I say configuration files (behaviours, bindings) are identical on both machines. Both configurations do specify includeExceptiondetailsInFaults = true.
I’ve also added a bunch of log statements that seem to indicate that the same code path is followed on both machines with the same values for various things like fault code, fault reason etc.
My dev machine is 2008R2 standard (64bit). The server in question is also 2008R2 Standard (64 bit).
I can post extracts of the code if required, but in the first instance is there anything environmental that could allow for what we’re seeing?
Extract from problem file:
<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>
Not 100% sure about etiquette here. This is an answer I guess to my specific brand of stupidity. Maybe somebody else will be as stupid, then the answer applies to them…
I was sure I had compared everything (I stated exactly the same code / configuration). But the behaviour configuration file I just gave a quick visual. After another developer approached me I realised that the local files were NOT the same as the server files. Doh!
In fact the server files had one extra line added by a post build step – triggering another custom behaviour which implemented IErrorHandler in addition to the IErrorHandler behaviour we already use for logging etc.
I guess I’m going to open another question now which seeks an answer to the approach on having multiple behaviours implementing the same interface and not polluting eachothers functionality (like returning Faults).