Sigh…

Now, when unit testing WCF Services, I’ve often ended up with cluttering my tests with a lot of plumbing code to wire up the SUT; that is – the WCF service I want to exercise.

Now, being a lazy guy, wiring up (redundant) plumbing code again and again, I often end up trying to extract the essence and put together a tool or helper class.

So, this is my first shot of a fluent helper class that lets you test your WCF services.

The screenshot below pretty much sums up the functionality. It should be pretty self explaining; You end up writing an Action<TContract> implementation that acts as the client.

It will wire up an OperationContextScope automatically, but it can be disabled if you don’t need it.

The state/quality of the code is “Proof of Concept” and can be found here.

• A lot of work
• Spending quality time with my son
• Hacking on different kinds of technology bits (mainly pieces released at the PDC 2008)

I’ve also tried to get a clear picture of my “blind spots” when it comes to WCF. Even though I feel quite competent, there are still tons of stuff that I don’t touch daily so I still have to “rehearse”.

Since I have “Get to know Workflow Foundation – for real” on my TODO list I spent some time playing with durable services.

The persistence provider mechanism that is located in System.WorkflowServices is not exclusive to to Workflows / Workflow services. It can also be used with “vanilla” WCF Services.

The idea is that the framework can persist the service instance after you have invoked a method and when a future method invocation comes down the wire, it can pull it from the persistence store – revive it and pass the call to the “same” instance. A perfect fit for the scenario of long running services.

So how do you enable durable services? It is quite easy. First, you decorate your service implementation with [DurableService] and one of the mechanisms that specifies that the type is serializable (I chose [Serializable] for the sake of simplicity).

In this code snippet we also see that there is another attribute that can be used to tell the persistence mechanism that a call to an operation creates the instance or tears it down; [DurableOperation].

The next thing you have to do is to wire up a persistence provider using either configuration or programmatically.

Out of the box there exists only one Persistence Provider; One suited for persisting the service instances to SQL Server – System.ServiceModel.Persistence.SqlPersistenceProviderFactory. You will have to set up a SQL Server Database instance with the schema located in C:\Windows\Microsoft.NET\Framework\v3.5\SQL\EN.

But that was a digression – now back to my custom “Velocity” Persistence Provider. If you don’t know what Codename “Velocity” is, I suggest that you head over here and read more about it. The short description:

It is Microsoft’s attempt to create an in-memory, high-performance, distributed caching supporting different scenarios that can suite many needs in both a web farm or other places where caching is needed. The current version that is publicly available is CTP2. We should expect a new CTP in March (around the time of MIX’09) and the RTW/RTM in the mid of 2009.

To implement a custom persistence provider, you will have to create two classes; the persistence provider implementation and its factory. It is the fully qualified type name of the factory that is specified when you set up the configuration.

The following configuration snippet shows how a custom service behavior is set up. You will have to set the behaviorConfiguration attribute on the service element to “defaultServiceBehavior” in this case.

The code for the provider is available here (Licensed under the Apache License 2.0).

Cheers

There should probably have been more time allocated for demonstrations but to cover all the areas of improvements in WCF (and related technologies) I really need (at least) 45 minutes. If I’m asked to do this talk for other NNUG chapters (or internal for other companies/clients) I think it would be wise to either cut down on the content – and only mention the left out parts briefly – or extend it to a two hour talk.

If you attended the talk, I would love feedback (both positive & negative), comments, questions, speaking & consultancy offers. Contact me at lw at miles dot no

You can download the slides here.

So I wrote a post in the WCF forum and asked if anyone knew where I could find it. No good answers, so I sent the question to a couple of the PM’s in Connected Systems Division that I know work with WCF. No answer. Finally I turned to the Email form on Nicholas Allen’s blog – and he was kind enough to mail me back.

Turn out that the bits is in the System.WorkflowServiceModel – one of the assemblies I didn’t bother to search since I thought they only contained Workflow-specific bits…

The invitation to the talk on Tuesday can be found here (In Norwegian). I’m hoping for at least 70-80 attendees.

My inital idea was to do an advanced extensibility talk, but after I attended the PDC in LA a couple of weeks ago I’ve changed my mind; the talk will be about the new features in WCF 4.0 (and I will probably touch WF 4.0 as well).

If there are anything special you want me to shed light on, please leave a comment or drop me a mail.

Thanks.

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.

• Miles Platform

  • Active Directory FOAF Gateway – internal beta
  • Active Directory Photo Uploader – internal beta
  • MOAT (Meaning Of A Tag) service / client – idea
  • Internal Library service / client – prototype

• WCF related

  • ChunkingChannelEx – bug fixing
  • XMPP Transport Channel – research/inception stage.
  • WCF Test Client Extended!

• Miscellaneous

  • Agressive – Silverlight-based, lightweight Time Management System – planning/prototyping stage.
  • Visual Studio Theme Explorer – planning phase.
  • Tinyject – A tiny IoC/DI container in about 200 lines of C#.

The idea is to release as many of these under a liberal open license – probably hosted on CodePlex or a similar service.

Some time ago, a user with the nickname refaeldakar asked in the WCF/MSDN forum how he could serve PDFs with the WebHttpBinding so that where shown as inline attachments in the web browser.

I wrote a small test application that did what he asked for. The trick here is to add an extra HTTP header to the outgoing response to the web browser; Content-disposition: “inline; filename=filenamehere.pdf".

The code can be found on here.

To manage the creation of service instances, you have to implement the IInstanceProvider interface, and wire up the concrete type in a service behavior.

The code should be fairly documented, and a simple xUnit.NET test project is included. If you want to check out xUnit.NET, check out its CodePlex site.

I’ve put the code on a new resource page on code.msdn.microsoft.com that I have created WCF Resources. You can find the release here.