We were all jumping for joy when Silverlight 2 beta 1 was released and the ability to connect to services was more readily/easily available to us. For discoverable services that provided a WSDL we were quickly able to implement them using the Add Service Reference capability in Visual Studio 2008. Beta 2 brings a few changes to the world of services that you should know about. I’ll do my best to recap some of them here.
Generating a WCF Service
In beta 1 when we created a WCF service for use in Silverlight, we used the “WCF Service” template in Visual Studio (assuming you used Visual Studio). This was fine and created a standard WCF service for us. There were a few changes that we had to make to ensure that our Silverlight application could consume it in an acceptable manner. First, we had to change the binding configuration in ASP.NET web.config from wsHttpBinding to basicHttpBinding as Silverlight only supports that binding type right now. Secondly, we might have had to add capabilities to enable ASP.NET compatibility support depending on what we were doing with the service. In beta 2, this process gets a bit simpler for services specifically built for Silverlight. After you install the tools for Visual Studio, you now get a new item type:
It is important to note that the WCF Service template is still a perfectly acceptable one to choose, you just have to ensure to make those changes accordingly. The new Silverlight-enabled WCF Service basically does those for us as well as add the ASP.NET compatibility attributes for us in the code. Additionally, the traditional interface/implementation is simplified into a single class. Again, the other ways are still valid, but for services specifically built for Silverlight, this might be an easier route to get them done.
Cross-domain policy file updates
Cross-domain restrictions still apply within beta 2 and the same rules apply. There is one subtle change that is required to your clientaccesspolicy.xml file that is required. In the allow-from node of the policy file, the attribute http-request-headers is now required. If your service is an open/public one then specifying “*” is probably acceptable (you’ll have to be the judge of that. If you only wanted to allow specific headers (besides the blacklisted ones) you can provide those in a comma-separated list and can use wildcards as well. For example you could use X-MyApp-* if you wanted.
Another thing to note about the support for Adobe’s crossdomain.xml policy file is one thing we found in interpretation of the policy template. Previously Flash was a Macromedia product and as such that file is adorned with a DOCTYPE that represents a schema with macromedia in it. Well, Adobe has changed the schema a little bit and also updated the DOCTYPE to reflect Adobe as the authority. Right now, Silverlight still expects to validate the macromedia declaration.
ServiceReferences.ClientConfig
In beta 1, when you performed the Add Service Reference operation a file named ServiceReferences.ClientConfig was created and had some configuration information in it. This file, however, wasn’t really used. In beta 2, this configuration file can be shipped with your XAP and used as configuration. It provides a subset of WCF configuration. Refined details of those settings are in the SDK, but I thought it might be helpful to know.
Change to WebClient
In beta 1, WebClient was the easiest library to use in accessing non-discoverable services. One challenge was that it only supported GET verb requests. In beta 2 WebClient has changed to enable POST verb actions as well. the UploadStringAsync function will send the request but the endpoint URI must be a URI that accepts the POST verb.
In addition, WebClient is now callable on a background thread in addition to the UI thread. This may come in handy for some situations.
I see these as small but helpful changes. Most are based on feedback we received from beta 1 customers and community, so thank you for that feedback. I hope this helps!
tags: silverlight, webclient, httpwebrequest, web services, wcf, wsdl, windows communication foundation, asmx, clientaccesspolicy, crossdomain, cross-domain, rest