Lars Wilhelmsen

With Visual Studio 2008 Microsoft bundled a new tool; the WCF Test Client (and its partner in crime; WcfSvcHost). The intention is good, but sadly the tool isn’t the one you pick up when you develop real-life services. (IMHO) The biggest shortcoming is the lack of functionality for saving and loading test data (templates) so you don’t have to enter the data manually each time you fire up the tool.

Last November, I attended the WCF Master Class held at Programutvkling’s premises right outside Oslo and the class instructor was Michèle L. Bustamante of IDesign.

During one of the first days when we still was going through some WCF Fundamentals, we came to discuss the shortcomings of the WCF Test Client, where raised the issue about the missing save/load functionality. I joked that I would see to that the functionality would be there in the end of the week.

Since I’ve played with WCF since the first Indigo bits went public, I had some “free” time during the first days when Michèle walked through the basics, so I set off on my mission equipped with .NET Reflector and VS2008.

I’ve done my amount of “Non-public binding” and .NET hacking before to get passed shortcomings and bugs in the Base Class Library and third part components before, so I had an idea of which strategy to go for.

The easiest solution would have been to use a .NET Reflector addin to disassemble the WcfTestClient.exe into a set of C# source files & a Visual Studio project.

That would have been too easy – and it would have prevented me to release the source code found below.

So the strategy I chose was to create a wrapper, that loads the original assembly, creates the main window  form, and inject the UI elements (Save/Load/About tool strip menu buttons).

Everything in the existing assembly is marked as internal, so all object construction and method invocation has to be done by binding to the members with BindingFlags.NonPublic | BindingFlags.Instance. Apart from that, it was really just a dirty job (but somebody had to do it, right? ).

Disclaimer: This code is only for educational purposes and is released to the public domain “AS-IS”.

You can find one of the ugliest hack I’ve ever done here.

Note: I asked a friend of mine, Anders Norås, to do a smoke test on the solution. On his Macbook he got an error when he tried to unzip the archive. So if you have any problems with the ZIP – you can try the RAR.

Instructions

Unpack the LarsW.WcfTestClientEx.zip to a suitable location and open the solution in Visual Studio 2008. There is an assumption in a post build event in the LarsW.WcfTestClientEx project that the original WcfTestClient.exe is located here at C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE. If you’ve installed Visual Studio to another location, you will have to change the post build event.

I’ve bundled a simple test service. If you’re running as a non-administrative user, you will probably have to either use netsh http add urlacl or httpcfg add urlacl to reserve http://localhost:12345/ – or change the service so that it uses another URI for the service endpoint that you have already registered.

Open the solution properties window and set the radio button to Multiple startup projects. Set both projects to Start.

When the WCF Test Client Extended! starts – it analyzes the metadata/WSDL from the service, and populates the operation tree.

Select on of the operations, and enter some test data into the generated UI grid.

Now, use the new Save… item on File menu and store the data to a file. Overwrite the data you entered with something else in the grid, and try the Load… item. Select the file you just persisted the test data to, and it should set the elements in the grid to the values you first entered.

Easy – isn’t it? Well, I have to admit that there is *no* error handling whatsoever, so there is probably a dozen ways the application can puke on you. This is just a proof of concept.

Later, I will show you have you can turn the WcfTestClient.exe into a scriptable console application, where you can specify the input data in one file, and the expected outcome in another (or you can just pipe the output and inspect it later) – could turn very useful for TDD purposes…

PS: One of the reasons I wrote this blog post now, was to have an excuse to advertise for Michèle’s WCF Master Class course starting 13th October 2008. Last time I checked, there was empty seats – so if I were you, I would head over here – and sign up. If you live in Scandinavia – it is really no excuse to skip this opportunity

Update: I just want to explicitly point out that the hack described above is not in the WCF Master Class curriculum.