by mheydt
26.
April 2009 19:19
>
When you deploy your web role to Azure (or the local development fabric), it will be assigned a url which is different from the one assigned by VS.NET, and which usually has a port of 81. This can cause problems in your Silverlight application if you call web services within the web role project. This is because VS.NET assigned a port to your web services (such as 43039). When deploying to Azure (or again the local development fabric), the app has a new (localhost:81 on the local dev fabric, and yet a different one in Azure), but the old ports (and a reference to localhost) remains in the proxy configuration(s).
So how can you solve this? The best scenario that I have found is to reconfigure your proxy URLs in the start up of the silverlight application. As an example:
What I'm doing here is calling this method during the startup of the Silverlight application object. It uses the HtmlPage.Document.DocumentUri object to determine the url to the application, and truncates it to contain just the address and port of the page that the application is served from the web server. The last two lines then create two proxy objects that I use in this app, and pass a new enpoint address object which is the base URI determined before appended with the asmx filename of the service. Note that you'll also need to pass in a binding object too; I change some parameters on mine, but using just a default BasicHttpBinding object should do fine (and it has to be a basic HTTP binding object as that is all that is supported by Silverlight).
This works for all deployments of the Silverlight application, either running locally in VS.NET, the local development fabric, or in Azure.