How can we make WCF support in Silverlight better?


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


Comments (26)

  1. Darrell says:

    Support for POCO.  It is a fair requirement to be able to use existing business layers as is, yet more than a notion currently to pull if off.  All examples I have seen assume the entity framework is available and WCF Ria Services has very little support for this huge reality.    

  2. Cool!

    Some extra suggestion: when deploying SL app on production service, sometimes I need to specify absolute address to third-party service, which also can be different for different services, so the I use the "annoying" fix. Is it possible to separate .xap file of application and .clientconfig file like assemblies when I choose "Reduce XAP size by using application library chaching" option? So I don't need to use archivers, just edit it in notepad.

  3. What we do for 2. Absolute service addresses in .clientConfig :

    We have sub folders in Silverlight project, one for each deployment environment (LOCAL, DEV, PROD)

    Each folder contains a *;clientConfig file with absolute address pointing to each environment :

    example :

    LOCAL .clientConfig contains URLs like http://localhost:1715/myservice.svc

    DEV .clientConfig contains URLs like contains devserver.mycompany.com/myservice.svc

    PROD  .clientConfig contains URLs like prodserver.mycompany.com/myservice.svc

    The main thing is, before building for deployment, to copy the file corresponding to the target environment at the root of the Silverlight project. Thus, the correct file will be packaged in XAP.

    Also, we use a secret key stroke in our apps (yes, we use Konami codes too 😉 ) to show a dialog box listing all endpoints urls by reading .clientConfig file at runtime. Thus, checking and debugging bad WCF urls became even more easier.

    Cheers

  4. surprise 😉 Add ws2007FederationHttpBinding.

  5. angie says:

    #2 – It would be great if the config transforms added for Web.config files in VS2010 could also be used for ServiceReferences.ClientConfig.

    Another pain point not included on this list is the inability to share WCF service and data contract assemblies between Silverlight and WCF projects. Right now I have to use the linked file workaround to share code.

  6. A. Benfield says:

    Yes, yes yes to PollingDuplex .clientConfig! Currently we've had to just make an XML file as a resource and use LINQ to XML to strip out any addressing/configuration for a duplex service which is not out own. Infact what would be better is a tool to modify the .clientConfig portions of a XAP for System Admin.

  7. A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  8. RIA Services says:

    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  9. A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  10. RIA Services says:

    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  11. Ben says:

    In regards to the cross domain issue, I have written up a lengthy post with examples and diagrams about how to configure a cross domain or client access policy for Silverlight.  This may help someone who is trying to troubleshoot this issue:

    http://www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

  12. daniel says:

    If you look at the fault WCF returns, having the message isnt that much help either.  Perhaps the team who developed the error handling knew that it would not be displayed and so didnt put much emphasis on it.  I suggest that MS provide a class to inherit from that automatically keeps meta data about that class, and so when the "error is return" if the class can also be returned, the error would be in there.

    For the service address problem IMO the best solution is to configure the endpoints in code and then use compiler directives to detect if debug or not, and if debug then use local and otherwise, use the production endpoints.  This could be the default implementation method and could be done in code for people, rather than how it is done now.  The downside to this is that there are sometimes QA environments between localhost and production.

  13. mike lorengo says:

    Polling Duplex. Anything you can do to make Polling Duplex functionality easier to integrate would be greatly appreciated.

  14. In this Issue: Ben Hodson , Marcel du Preez , Karl Shifflett ( -2- ), Rishi , Chris Koenig , Adam Kinney

  15. In this Issue: Ben Hodson , Marcel du Preez , Karl Shifflett ( -2- ), Rishi , Chris Koenig , Adam Kinney

  16. geekmasterzero says:

    I dont think WCF support in Silverlight is the issue, I think its more an issue of training.

    I had a hard time with WCF in the Silverlight 2 when info was a lot harder to find. if you do have problems 5 min spent on Bing or Google will point you in the right direction. If all else fails read the documentation!

    form my experience the people that have the hardest time of it are the guys who only RIA service templates and people who refuse to read documentation.

    What's needed most in IMHO is more in-depth how-to video's and walk throughs

  17. geekmasterzero says:

    I dont think WCF support in Silverlight is the issue, I think its more an issue of training.

    I had a hard time with WCF in the Silverlight 2 when info was a lot harder to find. if you do have problems 5 min spent on Bing or Google will point you in the right direction. If all else fails read the documentation!

    form my experience the people that have the hardest time of it are the guys who only RIA service templates and people who refuse to read documentation.

    What's needed most in IMHO is more in-depth how-to video's and walk throughs

  18. Adam Peled says:

    Hey,

    To add to the mentioned problems:

    1. Supporting creating/using proxy manually from service interface without using svcutil/Add service reference.

    2. Supporting synchronous activation of service calls if developer wishes (without Begin/End/Completed +=), I understand that you wish that service calls won't block the UI, but some of us developers still want the control in our hands (after all, blocking the UI thread is still possible using Thread.Sleep(X), even without service calls).

    3. Supporting raising/opening a WCF host in the browser – since you support Duplex & TCP, how far is it to also allow raising/hosting WCF server/service in the client side? this will allow for a lot greater performance for Pub/Sub scenarios, gaming scenarios (multiplayer mode), without playing around with TCP & sockets (I understand the security problems, but if you provide only specific ports like you have for TCP, it shouldn't be a problem).

  19. Adam Peled says:

    I already sent a comment, but it got deleted, so here goes the shorter version of improvements for Silverlight WCF stack:

    1. Adding support for synchronous server calls (I understand that you wanted to not block the UI thread when doing server calls, but it is still possible to block the UI Thread using Thread.Sleep()) – in short, developers want the power to also work in a synchronous manner.

    2. Adding support for opening a WCF host from silverlight client – I understand the security problems with it, but if you are already supporting TCP & HTTP Duplex, why not provide a secured (e.g. specific ports, used approval) means of also opening a WCF host? this will greatly improve supporting Pub/Sub scenarios and multiplayer games development in Silverlight.

    3. Working without svcutil/Add service reference – supporting working directly with the WCF interface (service contract), and creating a manual proxy for it – similar to regular .NET WCF scenarios.

    Regards,

    Adam

  20. I would love to see better support for Federated Identity solutions in WCF services within Sliverlight.

  21. Anil pandey says:

    Hi,

    I am having an OOb application in that i am using the polling duplex service but the problem is that while calling the service it return me the NOT FOUND error, but the same service in a silver light application is working fine.

    Could you please let me know what may be the cause for the same error? can we use the Duplex service in a OOB application???

  22. yavor says:

    Sorry for the delay in responding here – we have been having issues with our comment system.

    @Darrell – WCF proper does POCO happily today. I will pass along to WCF RIA Services folks… thanks

    @Leonid Andruhin – to make .clientConfig external to the .xap – good idea, thanks

    @Dominick Baier – 🙂 all I can say is that it's on the top of the list of most requested features, and is definitely being considered in the next version

    @angie – sorry, what config transforms are you referring to? Regarding sharing referenced types between WCF in .Net and Silverlight: that is absolutely being considered, thanks for the input.

    @Ben – that's a very useful post on cross-domain, thanks

    @daniel – I think sending your own type as a fault is already supported, please see the section on "Defined Faults"

    @mike lorengo – thanks, we will continue improving PollingDuplex

    @geekmasterzero – thanks for the feedback… we'll try to be more visible with our documentation content by doing more blog posts, Tweets, Silverlight TV episodes, etc.

    @Adam Peled – sorry for the comment issue

    #1 – regarding whether we can make proxy calls synchronous: I believe the browser just *cant* do synchronous IO, we could create a sync wrapper for you, but I wonder how useful that is

    #2 – regarding listening from within Silverlight: I don't think the browser supports this infrastructure. We are a browser plugin, so we work with what the browser gives us.

    #3 – regarding taking to proxies without Add Service Reference: Silverlight has the channel model, could you use that?

    @Michael McDowell – regarding federation, see comment to Dominick above

    Cheers,
    -Yavor

  23. http://www.iradriklis.net/ says:

    Ira Riklis                                                                                                                                                                           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.

  24. Jerry says:

    I really hope SL brings in WebHttpBinding. It is painful not being able to use WCF channel programming support to consume REST service.

  25. Don Casteel says:

    Please see my topic here:

    forums.silverlight.net/…/1