You create a new Silverlight WCF service and a snazzy new Silverlight application to access it to do all this cool stuff. You go in and add a Service Reference, click discover and it automatically finds your WCF for you. You wire up the events and code to make a call to the service…
You run up your Silverlight application and BAM – 404! But shouldn’t it just work?
Well if you get this problem it’s probably cross domain policy raining down on your parade. It kicks in when the domain you are requesting from is not the same as the domain you are requesting to. And yes, this may have just happened even though you aren’t exactly running a root DNS server in your bedroom at mum’s house.
What may be happening is that you are pressing F5 in Visual Studio, which then fires up your app on http://localhost/MyAwesomeApp – but in your Silverlight ServiceReferences.ClientConfig the endpoint address is set to http://devboxoftotalawesome/getrichquick/WebServices/Comments.svc.
Change this to the same URL that Visual Studio fires up your web site (and service) on and voila, your awesome WCF messages spill down the wire.
You may also want to consider editing your cross domain policy file – see the lovely Karen’s article here on this: http://scorbs.com/2008/04/15/silverlight-http-networking-stack-part-2-cross-domain-communication-overview/. Although this will fix the issue, remember that in production you probably do not want to go down this route unless you really do intend outside apps to access your services.
Also keep in mind that the cross domain policy file only works for (web)clients that adhere to it – such as Silverlight and Flash (Flash policy file). It’s important that note that adding a cross domain policy file does not protect your service from nefarious users… it merely prevents Silverlight and Flash apps from accessing your services. The only way to protect your sevices and other data sources from misuse is to apply security – like user authentication etc.