Calling an ASMX webservice from Silverlight? Use a static port.
The setup
Rob Conery recently posted on Creating a Web Service-Enabled Login Silverlight Control, which is probably a more important topic than many people realize right now. Since Silverlight code runs client side in the user's browser, many tasks like database access and user authentication require what is by definition a "web service" (even if it uses REST or some other, non-ASMX approach).
Along the way, Rob ran into an interesting issue. Being the wise man that he is, Rob knew that he faced a choice:
- Figure out an odd brain teaser dealing with undocumented alpha technologies
- Mention the odd brain teaser to Jon, who would likely get hooked and stay up all night figuring it out
Rob's a smart guy, you guess what he chose...
The problem
Microsoft Silverlight Tools Alpha for Visual Studio codename “Orcas” Beta 1 adds a new project type to Orcas - you guessed it, the Silverlight project. It does a few things - it adds the necessary references, adds an "Add Silverlight Link" context menu icon to other projects in your solution, does some sort of magic to make sure the the client side code compiles to ClientBin rather than Bin, and probably a lot of other important stuff.
The idea is that you create a solution with a Silverlight project, then create a separate web project, and then select "Add Silverlight Link..." to your web project.
Great, so here's the plan:
- We set up a Silverlight project and a Web (site or application) project
- We create a service in the web project
- We add a Silverlight link from the Web project to the Silverlight project
- We add a web reference to the Silverlight project, pointing to our webservice
Do all those intermingled references cause a problem? They can, if you don't set a static port for your web project (more on that later).
The main problem is that the ASP.NET Development Server (nee. Cassini) uses a random port by default, so when you add the webreference to your Silverlight project it adds via the dynamic port which has been assigned to that web project. The problem there, of course, is that since the port is randomly selected the webreference quickly gets out of sync with the webservice.
As I worked through the problem, I became convinced that the solution was to split the solution out into three projects - a main website, a Silverlight project, and a webservice website. I ran into a very interesting problem there. The problem is that the Silverlight control runs under the website's Cassini port, and the Webservice runs under a different Cassini port, and Silverlight's security model prevents it from accessing another port.
I'll try to say that again, this time in English. Let's say the main website is running on http://localhost:1000/Login.aspx and the webservice we want the Silverlight control to call is running on port 2000, as http://localhost:2000/LoginService.asmx.
The Silverlight BrowserHttpWebRequest sees different ports and throws the following exception:
"Cross domain calls are not supported by BrowserHttpWebRequest"
Really? I'm calling from localhost to localhost and I'm crossing domains? Yep. Reflector shows that pretty clearly - the IsCrossDomainRequest method compares on UriComponents.SchemeAndServer:
internal static bool IsCrossDomainRequest(Uri uri)
{
string components = uri.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped);
string text2 = HtmlPage.DocumentUri.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped);
if (components.Equals(text2, StringComparison.OrdinalIgnoreCase))
{
return false;
}
return true;
}
And UriComponents.SchemeAndServer includes port.
Hmm...
Rob and I discussed several options:
- Use IIS rather than Cassini. This isn't ideal, since it requires manual setup and clutters up your IIS installation on your local machine, but since IIS provides a distinct URL for your project without requiring a port, your reference won't change.
- Proxy requests by using the browser's XmlHttpRequest object, which can (probably) make cross-domain calls.
- Don't use a webservice, and call back to an ASPX page using a simple REST interface. In this case, there's no webreference to manage.
- Some other crazy rubbish involving hosts file entries which made sense at 3 AM, but sounds ridiculous right now.
None of those seemed right to me, which is why it took me so long to finish this post. The simple solution is to use one website project and set a static port number:
In this case, the Silverlight webreference has a set port and doesn't get out of whack. More important, by using one site running under one static port, both the page and webservice run under the same port and there's no cross-domain problem.