So if you’re like me, you’re on board with Silverlight and looking to get the most out of your RIA development. I’ve taken all the advice offered for creating Silverlight apps with WCF services- this video by Tim Heuer has been indispensable, but now we can create a Silverlight Enabled WCF service to avoid the modifications in web.config. When working on an application recently, I was somewhat confused by the error I received after deploying to my local friendly IIS server on the network:
HTTP/1.1 500 Internal Server Error
Date: Wed, 11 Mar 2009 20:37:29 GMT
Content-Type: text/xml; charset=utf-8
Accept-Encoding: gzip, deflate
What the heck is this, I thought? It worked perfectly well for days of testing running on localhost, but once deployed it broke (and badly as well, as nothing regarding my WCF service was working). So I did a little investigating…
The first thing I checked is whether the service is working on the server or not- that would be my first clue as to where my error might be coming from. I navigated to http://www.mysite.com/MyService.svc, and sure enough, I was able to see my service is running (along with a line showing the exact url, which is the same place I navigated to). So the service is running fine, scratch that off the problem list.
The next thing I try is to see if my Silverlight app runs without any references to the service, so I go into my project, comment out the calls to the Webservice, compile, and publish it to my server. Sure enough, the Silverlight app works fine as long as it doesn’t try to access the web service. Conclusion: something is going wrong in accessing the Webservice, but what?
As it turns out, Silverlight isn’t as intuitive as you would like it to be when publishing to a server when you have WCF services providing you with data. When you publish, you’re getting the .xap with the settings for running on localhost:port- VS doesn’t know where you are deploying to, so if you’re like me and running the WCF service within the same general site, all your references to any endpoint are going to still be pointing at your development machine when you publish it over to a server.
Now my approach has one advantage- I know the WCF service is running, and I know it’s running at http://www.mysite.com/MyService.svc, but what do I do with this little tidbit of knowledge? Go back into Visual Studio, into my Silverlight project, and update the following:
· In ServiceReferences.ClientConfig, plug in the service address for the server in the endpoint address field
· In ServiceReferences/ServiceReference, change the Client Address to my server address for the service
· In my .xaml.cs pages, instead of the usual MyServiceClient newClient = new MyServiceClient(), I’m instead dynamically grabbing the location of the endpoint as follows:
Uri Address = new Uri(Application.Current.Host.Source, "../MyService.svc");
var ReportClient = new MyServiceClient("BasicHttpBinding_MyService", Address.AbsoluteUri);
This grabs the location of the hosted Silverlight app, since it’s in a directory off of my base directory add the “../” to reference my service, and set my ReportClient to use my binding name (which you can view in ServiceReferences.ClientConfig) and my dynamically generated endpoint address. I then build this and copy the newly produced .xap into the ClientBin on my server, replacing the old one with the faulty references.
End result? Everything works like a charm, as my Silverlight application is now looking at the service on the same location and domain (no client access policy needed) and works as expected. Now when you are looking to use an auto-complete RadComboBox that Valeri showed us or populating a RadTreeview from WCF courtesy of this blog post from Kiril, you’ll know what happens when you publish to the server without changing your references.
Evan Hutnick works as a Developer Evangelist for Telerik specializing in Silverlight and WPF in addition to being a Microsoft MVP for Silverlight. After years as a development enthusiast in .Net technologies, he has been able to excel in XAML development helping to provide samples and expertise in these cutting edge technologies. You can find him on Twitter @EvanHutnick.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.