Question

I am working on a Silverlight application that uses WCF. I need to have my WCF project separate from the ASP.Net application that will host my Silverlight project. I am looking for some guidance on how I should organize my solution and list gotchas other people have experienced during debugging and deployment.

Specifically my questions are

1. What type of project should I use for the WCF service?(A WCF project, an ASP.NET project with self-hosted WCF services, something else)

2. What do I need to so to get it so that when I press F5 I can debug both my Silverlight project and my WCF service? Will I need a cross-domain policy just to debug the thing?

Some background info on why I want to do this:

I have legacy web application that I am gradually converting over to a Silverlight application. Because it is a large web application some of its features will be converted to Silverlight before others.

The legacy web application has lots of code in it that is no longer used. Much of the code that is no longer used references 3rd part assemblies. This is why I want to get rid of the old web application. So obviously I don’t want to host WCF services that will be kept for future versions in it. That is my reason for wanting to make the WCF project separate.

Answer 1

We’re doing the exact same thing.

1. We’re using a WCF project just in case we have to change how it’s hosted in the future. (I.E. no longer using IIS)

2.a. You can have a solution with your silverlight projects, and your wcf project. The silverlight project will have a service reference to the wcf service in your solution. That allows you to debug using F5. However, when you go to deploy, you will have to change your app.config service URIs to refer to your production location.

2.b. You will only need a cross-domain policy file if your fully qualified domain names are different for the wcf service and the silverlight app. Ours happen to be different. Here is an excellent article on when to use the policy file: Clicky

Good luck!