If you're used to debugging ASP.NET web applications together with WCF services, you will know that Visual Studio automatically attaches the debugger to the service process in addition to the website. When you It doesn't do this for services being called from Silverlight. Instead, Visual Studio will probably warn you that the service call will fail, but we've taken care of that problem with the behavior extension from the previous post.
The solution is fairly obvious: you will have to make sure that the debugger is attached to both your web application and your service.
If you've ever developed a Silverlight web application in conjunction with WCF services, you have probably run into some challenges when it comes to debugging the solution as a whole. Silverlight applications are limited to using services from the same server and port number as the application itself, unless the service explicitly allows external access through a clientaccesspolicy.xml file.
When using WCF to consume a web service from your .NET application, you have a couple of different options:
- Using a contract-only assembly reference, generating a proxy at runtime
- Generate a proxy by running svcutil.exe
- Adding a service reference to your project from Visual Studio
This post is focused on the last of these three options. When adding a service reference, Visual Studio presents you with a dialog box which allows you some level of control over the proxy being generated. One of these options allows you to choose the namespace for the generated classes.
Unfortunately, there is a small but annoying limitation on your ability to choose any namespace you like; Visual Studio will always prefix whatever namespace you enter with the current project's default namespace.