A couple of week ago a colleague of mine had a strange problem when running an ASP.NET WebForms application containing an UpdatePanel and a Response.Redirect inside a server side button click event handler. The same thing happened on my computer and yesterday I bumped into the same boring thing once more. I felt I had to find a proper solution to this!
WCF 4 comes with a bunch of new features where I find the service announcement and service discovery really cool. In this article I will implement a couple of services using these new features.
A couple of key words and classes for the scenario are SeviceDiscoveryBehavior, UdpAnnouncemenEndpoint, AnnouncementService. I will describe those classes along the way, but on MSDN you can find more information here: WCF Discovery Overview.
In my previous article I linked to a great article written by Aaron Skonnard, don’t miss it: A Developer’s Introduction to Windows Communication Foundation 4. It covers most of the new features in WCF 4, the simplified configuration, Workflow Services and a bunch of other stuff.
I will describe the scenario below along with a couple of code snippets.
The other day I wrote about sharing types between web services to simplify implementation of consumers of these services. You can read about it Multiple web service references sharing typeshere[/intlink]. I mentioned a nicer way to accomplish almost the same thing and I will present it here, by giving an example.
The biggest difference is that you have to define an interface, let all web service producers implement this interface and you as a consumer will be left with a minimal amount of work to consume all these web services as long as their end points are well known.
In this article I would like to point out a useful way to accomplish something that would be really easy, but still have been annoying me for the last couple of months. Imagine that you would like to get some data of some type from one web service and pass it on to another. The data types on both server sides are the same, but the compiler won’t let you pass the type from the first service on to the next one. Casting won’t work either, not without implementing some kind of home made casting method.
This is really really annoying, since the scenario stated above is really common in the web service world. I will present a solution to this, using the wsdl command line tool when adding web references instead of the built-in tool in Visual Studio.
Coming back from a little break during Christmas I looked around on the ASP.NET web site (http://www.asp.net) and found a couple of interesting newly added things. Amongst stuff I took a look at the coding standards added by Clint Edmonson (http://www.notsotrivial.net) a couple of days before Christmas. They look really nice and may be a good start when implementing some kind of standards in an organization.
The other day I got a question from a colleague of mine, regarding the XML schema usage when defining a web service interface, like the one defined in series. The question was something like this: “How will the consumer of the web service react if the, from the XSD file, auto-generated class used as in and return parameters is updated?” I couldn’t give a straight answer, other than that I assumed it would be transparent to the consumer as long as no nodes were changed or removed and only new nodes were added to the schema. I decided to give it a try, using a really simple XSD and a couple of really simple web methods. I will give a schematic picture of the scenario that I will test out later on.
In this article the actual MVC like design will start to show up. The previous article, , didn’t really have anthing to do with MVC, so let’s begin!
Almost all design patterns will make re-use of code easier, but to accomplish this it is important to setup the Visual Studio Solution in such a way to support this. In the setup I will show here I will make way for re-use and the implementation of the MVC design.

The other day I tried to compose an article about how to design an ASP.NET Web Service using an MVC like design pattern. I ended up with a huge article and decided to rewrite it and split it into a couple of smaller articles. I will try to write these articles as independent of each other as possible.
The idea to this subject came up when attending a course, held by Gabriel Svennerberg (http://www.svennerberg.com), dealing with Javascript, JSON and Javascript libraries such as JQuery and DOMAssistant. I wanted to try out the Ajax support in JQuery consuming web methods exposed by a regular SOAP web service as well as a WCF service. The business logic for these two interfaces were to be the same and their methods should have the same set of parameters, in and out. Therefore I wanted to create a couple of controllers and models to be used from the exposed methods. The methods themselves are the views in this MVC like architecture.
In this article I will explain how to implement a custom SOAP extension to be able log all incoming and outgoing SOAP messages passing through a .NET web service.
Sometimes the IIS log file is not enough when debugging or looking for errors in a web service. Let’s say that the web service works like a charm in the development environment, but then when a third party user starts invoking methods in the production environment it stops doing what it was built for. Then you have a need for this little extension, letting you log and analyze all incoming messages as well as the outgoing.