You should be catching FaultException<ServiceException> and not FaultException<ServiceFault>

Even then it's not working. The XML. Let me reiterate that the custom handler that you are using was written before EntLib exception shielding. I think exception shielding should do what you want. If not, then why not?

Thank you for such a comprehensive explanation. Until now I'd not realised, the concept I was trying to implement was something before exceptionshileding. everything you've explained above makes complete sense and thanks for the same.

It works as expected for me.

I wanted to use exceptionshileding as we do not intend to implement try-catch in our services.

I'd posted few qns a week ago and I guess i'm already doing what I need to. I jsut need more members in my serviceException datacontract.

Is this obvious as there're no datamembers? or am I missing anything again? Please help.

I Either want to have ServiceException as my faultContract or below class as my faultcontract. if I use below class, can You help me understand how I can fill the Data Dictionary? I do not want to expose this as configurable property. I believe I need
customhandler? I essentially need to have more than just a Msg and Guid in my faultexception.

If you are using a Service Reference then you should make sure you are catching a FaultException<ServiceReference.ServiceException> (or whatever your service proxy class is called) and not the actual server side ServiceException since those would be
different classes.

If you are changing the ServiceException definition then also be sure to update the service reference. I've seen it fall into the FaultException catch when the references haven't been updated.

As for the IDictionary problem I'm not sure I follow. You want to populate an IDictionary without exposing it as a property? If it's just mapping the exception Data property to your ServiceFault property then you can do that through configuration
as a <mapping>.

I'm not 100% sure what you are experiencing but I would recommend not to pass back general Exceptions or IDictionary through your WCF interface. Not only will you probably run into serialization issues but you are limiting interoperability as well.
For example if you try to return an InvalidCastException as the InnerException then WCF is going to complain:

Type 'System.InvalidCastException' with data contract name 'InvalidCastException:http://schemas.datacontract.org/2004/07/System' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types -
for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.

If you really want to use WCF with an all .NET solution perhaps consider using the
NetDataContractSerializer which includes CLR information in the generated XML and is quite powerful when the same .NET types exist on both sides of the wire. Of course, this is not very interoperable.

to start with, ent lib was brand new to me. still is. so I started with a prototype and this is how I landed up. I wouldn't be catching inner exceptions in the datacontract. nor the IData

the reason I put that in the code was to just check if any of the properties other than Guid and Messages are even caught.

My objective here essentially is to include little more information than just Guid or message. when the faultexception gets propogated to the client.although this information will not be shown to the client, UI developers will need bit more details than
jsut one line error message and its guid.

your inputs would really help and would be very valuable. I also need to log the errors at service end. i'm doing it now but at very basic level. need to attend this sometime soon