Compartir a través de

How can we make WCF support in Silverlight better?

  • Artículo

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 https://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

  • Anonymous
    June 29, 2010
    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.    

  • Anonymous
    June 29, 2010
    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.

  • Anonymous
    June 29, 2010
    The comment has been removed

  • Anonymous
    June 29, 2010
    surprise ;) Add ws2007FederationHttpBinding.

  • Anonymous
    June 29, 2010
    #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.

  • Anonymous
    June 30, 2010
    The comment has been removed

  • Anonymous
    June 30, 2010
    Top issues for Silverlight

  • Anonymous
    June 30, 2010
    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  • Anonymous
    June 30, 2010
    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  • Anonymous
    June 30, 2010
    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  • Anonymous
    June 30, 2010
    A while back I had sent out an update on Twitter that I was sitting in a meeting reviewing some “top

  • Anonymous
    June 30, 2010
    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: www.devtoolshed.com/explanation-cross-domain-and-client-access-policy-files-silverlight

  • Anonymous
    June 30, 2010
    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.

  • Anonymous
    June 30, 2010
    Polling Duplex. Anything you can do to make Polling Duplex functionality easier to integrate would be greatly appreciated.

  • Anonymous
    July 01, 2010
    In this Issue: Ben Hodson , Marcel du Preez , Karl Shifflett ( -2- ), Rishi , Chris Koenig , Adam Kinney

  • Anonymous
    July 01, 2010
    In this Issue: Ben Hodson , Marcel du Preez , Karl Shifflett ( -2- ), Rishi , Chris Koenig , Adam Kinney

  • Anonymous
    July 01, 2010
    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

  • Anonymous
    July 01, 2010
    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

  • Anonymous
    July 05, 2010
    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).
  • Anonymous
    July 05, 2010
    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

  • Anonymous
    July 05, 2010
    I would love to see better support for Federated Identity solutions in WCF services within Sliverlight.

  • Anonymous
    July 06, 2010
    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???

  • Anonymous
    July 19, 2010
    The comment has been removed

  • Anonymous
    September 26, 2010
    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.

  • Anonymous
    October 21, 2010
    I really hope SL brings in WebHttpBinding. It is painful not being able to use WCF channel programming support to consume REST service.

  • Anonymous
    August 28, 2011
    Please see my topic here: forums.silverlight.net/.../1