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:

  1. Figure out an odd brain teaser dealing with undocumented alpha technologies
  2. 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:

  1. We set up a Silverlight project and a Web (site or application) project
  2. We create a service in the web project
  3. We add a Silverlight link from the Web project to the Silverlight project
  4. 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.


Rob and I discussed several options:

  1. 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.
  2. Proxy requests by using the browser's XmlHttpRequest object, which can (probably) make cross-domain calls.
  3. 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.
  4. 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:

 Webservice with static port

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.


  • I was facing the same issue with a WCF service hosted in casini and a client, and solved the same way. Great minds think alike :)

  • Hi,
    When I am going to debug my silverlight project it says that the projet you are trying to debug is consuming web services. Calls to the Web Service will fail unless the project is executed in the context of the web which contains the web services.
    Can you help me to know what does this mean?

    I am using IIS as the web server. The web service works fine separately but the call from from the silverlight project just hangs indefinitely.

  • Yeah. I think we can't set the same port for both web service and website... Instead, we can put everything in one project.. but I don't think this is good idea...

  • hjnhhbnn
    mbbnnm, nbbnj
    nbbnb, bbmbnmbn
    bhbbb bnmnnn,nnm
    bbjgv bmvmblbbm b
    bbbnbvn bnbmbmb,bb
    bnnbb bnbmbbmnnmn

  • Hello there! This is my first visit to your blog!

    We are a collection of volunteers and starting a new initiative in a community in the same niche.
    Your blog provided us valuable information to work on.
    You have done a marvellous job!

  • Asking questions are actually good thing if you are not understanding anything entirely, but this
    piece of writing presents good understanding even.

Comments have been disabled for this content.