17. April 2011 15:53
Earlier today, I blogged about a reusable behavior extension to make debugging Silverlight apps a little easier. I wrote most of that article months ago and in the meantime I've added a second behavior extension to support Silverlight software development. I included it with the download, but some explanation about its purpose might be in order.
17. April 2011 12:16
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.
17. April 2011 07:51
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.
8. August 2010 16:25
Last week, I got an e-mail from a customer using our web services. They were wondering some operations were not working properly when no input parameters were given. This raised an eyebrow at first, as my documentation clearly stated that this information was mandatory.
It would soon become clear, that the developer in question did not read said documentation at all, but was in fact flying blind on the WSDL. Indeed, the input message schema said everything was optional; this is default behavior for WCF. In this article, I'll work on fixing this minor caveat in the interest of interoperability.
30. May 2010 18:40
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.
30. May 2010 10:12
I have spent a considerable amount of time on development in a service-oriented architecture. On the Microsoft platform, the technology of choice is WCF (Windows Communication Foundation). Generally, it is a great technology, but it does have its nuisances. One of them is the way certain error conditions are handled when consuming web services.