The way I got it to work was by using a proxy to an asmx service in my web application, which is a proxy to the WCF service. This is because Silverlight and WCF don't like each other, so you can use a web application to mediate and make them play
nicer (see #3 below). The structure is like this:
The solution contains a Silverlight 1.1 application, an ASP.NET Futures application and a WCF service project. The ASP.NET Futures application contains an asmx service implementing the WCF service contract and passing through to that service. A proxy class
for the asmx service is generated using slwsdl.exe and added to the Silverlight application (See #1 below. Use that proxy in your Silverlight app to call your service methods.) The hookup is completed by adding a Silverlight link to the web application and
using the ASP.NET Futures XamlControl to host your Silverlight content.
Some things to consider about this approach:
You'll need to manually set the Url property of the generated Silverlight proxy to the relative path of the asmx service in the web application. Since the Silverlight content will reside in the web application, the relative Url will resolve to the asmx
service. This is how you get around the cross domain calls exception the BrowserHttpWebRequest likes to throw.
You can't debug the service calls in your Silverlight application -- you have to do it from the web application. The Silverlight application won't function independently because it needs the asmx service in the web application. And System.ServiceModel
and Silverlight don't like each other, so you can't implement the asmx proxy in Silverlight. At least I couldn't figure out how.
Something about what is happening under the hood fails service methods with multiple arguments. I've seen stuff out there talking about this, but I can't recall the reason. Should be easy enough to find. This is the big ugly for me.
I can provide a base implementation if you'd like. I'm not sure if this is the best way to do it, but it worked for me and doesn't require too much smoke and mirrors or compromise.
MyMindsOwn
Member
52 Points
22 Posts
Re: Example of using WCF with Silverlight 1.1
Oct 18, 2007 04:46 PM | LINK
The way I got it to work was by using a proxy to an asmx service in my web application, which is a proxy to the WCF service. This is because Silverlight and WCF don't like each other, so you can use a web application to mediate and make them play nicer (see #3 below). The structure is like this:
The solution contains a Silverlight 1.1 application, an ASP.NET Futures application and a WCF service project. The ASP.NET Futures application contains an asmx service implementing the WCF service contract and passing through to that service. A proxy class for the asmx service is generated using slwsdl.exe and added to the Silverlight application (See #1 below. Use that proxy in your Silverlight app to call your service methods.) The hookup is completed by adding a Silverlight link to the web application and using the ASP.NET Futures XamlControl to host your Silverlight content.
Some things to consider about this approach:
I can provide a base implementation if you'd like. I'm not sure if this is the best way to do it, but it worked for me and doesn't require too much smoke and mirrors or compromise.