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?

1. NotFound errors

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.

2. Absolute service addresses in .clientConfig

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.

3. Support for PollingDuplex services in .clientConfig

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.

4. Debugging cross-domain errors

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?

  1. Item template (similar to Tim Heuer’s online template). The drawback of this approach is that the developer needs to know that they are missing a policy file, and know the correct location where to add that file (at the root of the web server, not an arbitrary web application).
  2. Better Add Service Reference integration. Currently Add Service Reference will detect the lack of a cross-domain calls in some situations and warn you with a compile-time warning. This feature can be made more robust.
  3. Standalone tool. Potentially we could design a tool that lets you enter the address where you want to host the .xap package and the address of the service that you are trying to access. The tool could verify whether the correct policy file is present, and if not, it could even generate an example policy file that you can send to the service owner.
  4. A WCF proxy service. We could provide an out-of-the-box WCF proxy service that can easily be hosted in the same  web application as the .xap itself. You can then use that service to make a call to any remote destination, without worrying about cross-domain.

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