As I learn more about WCF, especially as it’s consumed by Silverlight, the better equipped I am to identify and solve problems. This is what I keep telling myself as a justification for the time I spend and angst I feel sometimes as I feel my way through my first significant Silverlight application.
I am far enough along that I wanted to add a deployment step to by build process which would copy all the requisite application files to a web server I have running at home. My main goal was to iteratively deploy the application, as it progressed, so some folks whose opinions matter to me could look at and play with the application and give me feedback.
When I created the Visual Studio solution for my application, I elected to have VS create a web application for me and my .xap file and WCF services are both hosted in that application. So, as I develop, I’m typically working in a mode where I’m running the web application in the development web server so I can make service changes on the fly. This all worked fine in regard to being able to communicate with my services from the Silverlight application.
I realized, after deploying, that my Silverlight application would need to talk to services running on my server instead of locahost, so before checking in the code each time, I changed my service references to point to services located there. More specifically, to point to a domain I have set up for that server. I checked in, the build deployed the application, I tested and found no joy at all. As I investigated, I discovered that when I set my service references to point to my domain (http://www.domain.com/MyService.svc) what was actually being recorded in web.config and the artifacts that were created by adding the reference was http://machineName/MyService.svc. After a good bit of research and thinking about the problem, I found the solution.
The root of the problem has nothing to do with Silverlight or WCF. It’s actually a web site configuration issue that can be corrected by going to the Internet Information Services MMC Snap-In, and drilling down to your web site. Note that if IIS is listening on only one port, this will be the “Default Web Site”. In IIS 6 and before, you’ll want to go to the “Web Site” tab and click the “Advanced” button. You should see a window like the one below.
Notice that this site is listening on port 80 and has no Host Header Name and so the default value is used which is the name of the machine IIS is running on. To correct the problem, select the one row and click the edit button. Then, fill in the Host Header Name such that it matches your domain like www.domain.com and click OK.
For IIS 7, select the web site in the tree view, select the “IPv4 Address and Domain” icon and then click the “Bindings” link on the right hand side. Select the record for port 80 and click the Edit button.
Enter your host name, as above, and click the OK button and then the Close button.
After making this change, your service references should be scoped to your domain instead of to the machine name.