Feddas - Shawn Featherly

Can't get fiddler to listen to any of the traffic on the new app you are building? It's because Fiddler doesn't listen to traffic on the localhost by default. Fiddler recommends using ipv4.fiddler in place of localhost to capture localhost messages. To do this with a silverlight service you'd modify your Silverlight apps ServiceReferences.ClientConfig file to something such as the following.

            <endpoint address="http://ipv4.fiddler:2119/WCFservice.svc" binding="customBinding" bindingConfiguration="CustomBinding_WCFservice" contract="WCFServiceReference.WCFservice" name="CustomBinding_WCFservice" />

        </client>

    </system.serviceModel>

Or by using the new Silverlight 4.0 relative address feature.

            <endpoint address="../WCFservice.svc" binding="customBinding" bindingConfiguration="CustomBinding_WCFservice" contract="WCFServiceReference.WCFservice" name="CustomBinding_WCFservice" />

        </client>

    </system.serviceModel>

Yet this crops up a new cross domain issue when running the application. This is because ipv4.fiddler is considered a different domain than localhost. The fix is fairly easy, get rid of localhost in the URL you use to request the local app:
http://ipv4.fiddler:2119/SilverlightTestPage.aspx

Reference:
starts 18:25 minutes into http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-46-Whats-Wrong-with-my-WCF-Service
http://blogs.msdn.com/b/silverlightws/archive/2010/05/10/fiddler-inspector-for-wcf-silverlight-polling-duplex-and-wcf-ria.aspx

Labels: cross-domain, Fiddler, Silverlight

Setting <serviceDebug includeExceptionDetailInFaults="true" /> in a Silverlight ServiceReference's web.config seems to keep the same old "NotFound" details when an exception is thrown when a Silverlight app makes a call to it. Today I found out why; the Browser stack does not capture much in regard to fault details.

Silverlight uses two different stacks; the Client stack and the Browser stack.

Client stack is not the default stack. However, it has better handling of WCF error and status codes. To switch to the Client stack add the line below to your silverlight UserControls constructor:

public MainPage()

{

  InitializeComponent();

  WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);

}

After this you'll see everything about the exception that was thrown by the WCF service, From the exception type to the entire call stack.

After you've debugged your WCF service you should switch back to the Browser stack, not only for security reason but that default browser stack handles windows authentication and automatic cookie handling.

Reference:
starts 11:48 minutes into http://channel9.msdn.com/Shows/SilverlightTV/Silverlight-TV-46-Whats-Wrong-with-my-WCF-Service

Labels: Faults, includeExceptionDetailInFaults, Silverlight, WCF