Cross-domain WCF service calls from Silverlight are nice to have. But I don't see them being the norm for most Silverlight controls mainly because most of the time, we'll want to keep the services exposed from the web tier in lock-step with the Silverlight controls that consume them from a deployment standpoint. The simplest way to do that is to treat the WCF calls that come from the browser like any other web page or callback that the browser might consume. This will avoid having to inject a location into the container (page) for the Silverlight control or from having to use an external service locator to find it.

OK, so assuming you have a rule requiring that every service object will be located relative to the pages hosting a Silverlight control, this little bit of Silverlight code will build an EndpointAddress that targets a service called MyService.svc in the same virtual directory:

You'll need to import the System.Windows.Browser namespace to use the HtmlPage class in this way. As you can imagine, the static Document property on the HtmlPage gives you almost full access to the DOM for the containing page. We're just using the DocumentUri property of it to find out where the hosting page emanated from, lopping off the page name and adding the service (page) name. When you're debugging with the Cassini web server which assigns port addresses dynamically, this is a nice way to make sure that you always connect back to the same server instance that served the current page.