I (very foolishly) spent a few minutes today trying to figure out why applying WCF tracing configuration to a ADO.NET Data Services client (i.e. a proxy generated with webdatagen.exe) wasn't producing me any tracing results.

It didn't take too long to realise that the client proxy isn't actually a WCF proxy. It just uses HttpWebRequest directly.

If you want WCF tracing, put your configuration onto your service side code.

I didn't actually find WCF that useful in tracing messages here and so fell back to inserting a proxy and tracing at the HTTP level.

That didn't work perfectly for me either - I found most value by taking my Entity Framework class (i.e. the class that derives from ObjectContext) and then adding another class which derives from that, handling the SavingChanges event in the constructor and then sticking a breakpoint in my event handler server-side in order that I could have a look at the ObjectStateManager as calls come in from Data Services layer.

What I mean here is...

public class MyContext : demoEntities
{
  public MyContext()
  {
    this.SavingChanges += OnSavingChanges;
  }

  void OnSavingChanges(object sender, EventArgs e)
  {
    Debugger.Break();

    // Now we can use the debugger to look at the object
    // state manager.
    ObjectStateManager m = this.ObjectStateManager;
  }
}

where demoEntities is the ObjectContext-derived class that the EF tooling spits out for me from my database. That class is a partial class but the generation tool already throws out a default constructor so I thought it would be "better" to derive here.