Friday, April 25, 2008

Trouble with Silverlight/WCF deployment

We’ve been having a lot of trouble moving Silverlight projects from development machines to production servers recently. This is especially true of new Silverlight beta 2 projects using WCF as the data communication layer. The problem seems to be when we try and move from a VS2008 development environment (where the WCF service runs by default off the in-built VS web server) to an IIS based production server. We don’t want to be running a temporary web server on a production environment (indeed we normally wouldn’t even have one as the development environment would not be installed) and we can’t link the Silverlight project to the “localhost” implementation of the WCF service.

So we have to change the addressing of the Silverlight web service from localhost to and we have to run the web service from the IIS rather than the temporary web server it would normally run from when you run the project on the development machine. These changes have led to us seeing a lot of errors involving:
1) Endpoints mismatches
2) Cross domain security
3) IIS configuration issues
4) References not updating

We haven’t solved all the above consistently, but through a lot of trial and error we have got our projects deployed online. The things to look out for:
1) Register .xap files as MIME types in IIS
2) Modify the projects to all use the IIS server on the developer machines instead of the default web server
3) Put the WCF service on the deployment server, and then modify the web reference in Silverlight to point to the deployment server instead of localhost, then add the Silverlight project to the deployment server
4) Modify the hosts file on the deployment server to point your domain name to so you can use the project on the server as well as remotely
5) Use clientaccesspolicy.xml to avoid cross domain issues
6) When re-referencing to a new web service, you should do a search through all files in the project for the original reference (e.g. “localhost”). We had a problem where some .config files didn’t auto-update and we had to manually change this reference.

Needless to say, we aren’t the only ones facing deployment problems with 2.0 beta, so here are some links to others solutions:

Scott Tattersall is lead developer of stock alerts, stock charts, and market sentiment for Zignals