Sometimes as a team we get carried away trying to add new features to the product, when we should actually focus on improving the usability of existing features from previous releases. I’ve put together a list of WCF pain points that we are aware of based on what we’ve heard through forums, our support channels, and conversations with customers who have contacted us via this blog. I’ve also listed (in italics) the proposed fix we are considering in the next version of Silverlight.
What’s the most annoying WCF pain point for you?
Everyone who has worked with WCF in Silverlight has probably encountered a “NotFound” CommunicationException. What is really happening is that the WCF service is returning a fault, but Silverlight cannot read it. This has been documented well and the workarounds are listed in this MSDN topic. Effectively there are two workarounds depending on whether you are using the BrowserHttp or ClientHttp network stack. If the BrowserHttp stack is used, then a service behavior needs to be applied to the WCF service. If the ClientHttp network stack is used, then no extra work is needed; faults will just work.
The problem here is that since the BrowserHttp stack is the default in Silverlight, most customers will have to apply the service behavior, but they need to go to the documentation to find out how to do that. So out of the box, the faults experience is broken.
What we are considering here is modifying the Silverlight-enabled WCF Service template to include the faults behavior out of the box. This way faults will “just work” for all customers who start with the template.
By default when you invoke Add Service Reference in Visual Studio, it will generate a .clientConfig file which contains the binding and address for the service you are trying to access. The problem is that the service address generated is always a absolute address, such as http://localhost:1234/Service1.svc. If you then take the web application containing the Silverlight .xap package out of Visual Studio and try to deploy it to a production machine, the absolute service address will no longer be correct, so the WCF calls will fail. The fix is simple, but annoying: when you deploy, you have to unzip the .xap package, manually edit the .clientConfig to correct the address, then zip the .xap file back up.
Part of the solution was already shipped in Silverlight 4, and is described in this documentation topic (check the section “Configuring the Service Address”). This feature gives you the ability to specify relative service addresses such as address="../Service1.svc". However the problem is that Add Service Reference by default will still generate absolute addresses by default. So the proposed feature here is to make Add Service Reference generate relative addresses by default. This way the address will always be correct, as long as the .xap and the .svc file are moved together.
Currently when you generate a proxy to a PollingDuplex service using Add Service Reference, we do not generate the binding and address information in .clientConfig. The user has to manually specify the binding and address in the proxy constructor method.
The suggestion here is to modify Add Service Reference so it generates config for PollingDuplex services, just like it does for regular WCF services and NetTcp services.
Cross domain errors have been by far the most common issue reported by customers since Silverlight 2. It’s also hard to come up with an easy solution to the problem.
Here are some suggestions… which one do you prefer?
Please use the comments on this post to put these pain points in order of importance to you. Also feel free to suggest new things that we may not have thought of.
Cheers, -Yavor Georgiev Program Manager, WCF