c# – Krzysztof Koźmic

On C# dynamic and calling base type’s methods

The dynamic keyword has been part of the C# language for quite a while now. I thought I know it well, yet I stumbled upon an interesting case that surprised me.

The code that works

Here’s a piece of code that I started with. This code works like you would expect.

public interface ICanQuack
{
    void Fly<T>(T map);
    void Quack();
}

public class Duck : ICanQuack
{
    public void Fly<T>(T map)
    {
        Console.WriteLine("Flying using a {0} map ({1})", typeof (T).Name, map);
    }

    public void Quack()
    {
        Console.WriteLine("Quack Quack!");
    }
}

class Program
{
    private static ICanQuack quack;
    private static void Main(string[] args)
    {
        SetUpQuack();

        var map = GetMap();

        quack.Fly((dynamic)map);

        Console.ReadKey(true);
    }

    private static void SetUpQuack()
    {
        quack = new Duck();
    }

    private static object GetMap()
    {
        return "a map";
    }
}

Notice the use of dynamic to resolve the generic method type parameter at runtime. This code works and, as you probably guessed, prints:

Flying using a String map (a map)

The innocent change that broke it

Now, even though it’s a completely made up example instead of the real code, flying is something not just ducks do, so let’s extract an interface ICanFly

public interface ICanFly
{
    void Fly<T>(T map);
}

public interface ICanQuack : ICanFly
{
    void Quack();
}

Rest of the code stays the same.

Looks innocent enough right? Except it just broke out code. It we run it now we’ll get the following error
Error

What happened

Well, to be honest, I’m not quite sure I have a good explanation for the behaviour. Like I said, I was surprised myself that this code stops working now. When you use the dynamic keyword C# compiler tries to use all the information it has at compile time, to optimise the code it generates to support the dynamic invocation, so that it has less work to do at runtime. In this case, by definition, everything that implements ICanQuack also implements ICanFly but the binder seems to not bother checking the base interface. I’m sure Jon Skeet has a perfectly good explanation for it.

How to fix it

The exception message points us pretty clearly towards the problem – the runtime binder uses the static type information about ICanQuack to find the Fly method. Since the method is defined on the ICanFly interface, we need to give the binder a hint that ICanFly is where it should look.

To do that, we need to change the following code

quack.Fly((dynamic)map);

into a bit uglier (but working!):

((ICanFly)quack).Fly((dynamic)map);

November 27, 2013

Using Resharper to ease mocking with NSubstitute

The problem

While C# compiler provides a decent level of generic parameter type inference there’s a bunch of scenarios where it does not work, and you have to specify the generic parameters explicitly.

One such case is when you invoke a generic method inline, and the return type is the generic type parameter.

In other words, the following scenario:

In this case the compiler won’t infer the generic parameter of GenericMethod and you have to specify it explicitly.

As helpful as Resharper often is, it also doesn’t currently provide any help (other than placing the cursor at the appropriate location) and you have to specify the type parameter yourself.

Oh the typing!

I’m quite sensitive to friction in my development work, and I found this limitation quite annoying. Especially that the pattern is used quite often.

Specifically the excellent NSubstitute mocking framework is using it for creation of mocks via

Substitute.For<IMyTypeToMock>();

method.

If I wanted to use NSubstitute to provide the argument for my GenericMethod I’d have to do quite a lot of typing:

type Su or few more characters to position completion on the Substitute class.

Press Enter.

Type . and assuming the right overload of For is selected press Enter again (or press arrow to pick the right overload before that).

Finally, type enough of the expected type’s name for completion to select it, and press Enter to finish the statement.

It may not look like much but if you’re writing a lot of tests those things add up. It ends up being just enough repetitive typing to break the flow of thoughts and make you concentrate on the irrelevant mechanics (how to create a mock for IFoo) rather than what your test is supposed to be doing (verifying behavior of UsesIFoo method when a non-null arg is passed).

Resharper to the rescue

While there’s no easy way to solve the general problem, we can use Resharper to help us solve it in this specific case with NSubstitute (or any other API, I’m using NSubstitute as an example here).

For that, we’ll write a Smart Template.

How to: writing a Smart Template

Go to Resharper menu, and pick Templates Explorer…

Make sure you’re on the Live Templates tab, and click New Template.

For Shortcut select whatever you want to appear in your code completion for the template, for example NSub.

Select the template should be allowed in C# where expression is allowed.

Check Reformat and Shorten qualified references checkboxes and proceed to specifying the template itself, as follows:

NSubstitute.Substitute.For<$type$>()

The $type$ is a template variable, and the grid on the right hand side allows us to associate a macro with it. That’s where the magic happens.

Pick Change macro… and select Guess type expected at this point.

After you’ve done all of that, make sure you save the template.

Result

Now your template will be available in the code completion.

All it takes to get to the end result now is to type ns, Enter, Enter.

The main benefit though is not the keystrokes you save, but the fact there’s almost no friction to the process, so you don’t get distracted from thinking about logic of your test.

December 18, 2012

Approval testing – value for the money

I am a believer in the value of testing. However not all tests are equal, and actually not all tests provide value at all. Raise your hand if you’ve ever seen (unit) tests that tested every corner case of trivial piece of code that’s used once in a blue moon in an obscure part of the system. Raise your other hand if that test code was not written by human but generated.

As with any type of code, test code is a liability. It takes time to write it, and then it takes even more time to read it and maintain it. Considering time is money, rather then blindly unit testing everything we need to constantly ask ourselves how do we get the best value for the money – what’s the best way to spend time writing code, to write the least amount of it, to best cover the widest range of possible failures in the most maintainable fashion.

Notice we’re optimising quite a few variables here. We don’t want to blindly write plenty of code, we don’t want to write sloppy code, and we want the test code to properly fulfil its role as our safety net, alarming us early when things are about to go belly up.

Testing conventions

What many people seem to find challenging to test is conventions in their code. When all you have is a hammer (unit testing) it’s hard to hit a nail, that not only isn’t really a nail, but isn’t really explicitly there to being with. To make matters worse the compiler is not going to help you really either. How would it know that LoginController not implementing IController is a problem? How would it know that the new dependency you introduced onto the controller is not registered in your IoC container? How would it know that the public method on your NHibernate entity needs to be virtual?

In some cases the tool you’re using will provide some level of validation itself. NHibernate knows the methods ought to be virtual and will give you quite good exception message when you set it up. You can verify that quite easily in a simple test. Not everything is so black and white however. One of diagnostics provided by Castle Windsor is called “Potentially misconfigured components”. Notice the vagueness of the first word. They might be misconfigured, but not necessarily are – it all depends on how you’re using them and the tool itself cannot know that. How do you test that efficiently?

Enter approval testing

One possible solution to that, which we’ve been quite successfully using on my current project is approval testing. The concept is very simple. You write a test that runs producing an output. Then the output is reviewed by someone, and assuming it’s correct, it’s marked as approved and committed to the VCS repository. On subsequent runs the output is generated again, and compared against approved version. If they are different the test fails, at which point someone needs to review the change and either mark the new version as approved (when the change is legitimate) or fix the code, if the change is a bug.

If the explanation above seems dry and abstract let’s go through an example. Windsor 3 introduced way to programmatically access its diagnostics. We can therefore write a test looking through the potentially misconfigured components, so that we get notified if something on the list changes. I’ll be using ApprovalTests library for that.

[Test] 
public void Approved_potentially_misconfigured_components() 
{ 
    var container = new WindsorContainer(); 
    container.Install(FromAssembly.Containing<HomeController>());

    var handlers = GetPotentiallyMisconfiguredComponents(container); 
    var message = new StringBuilder(); 
    var inspector = new DependencyInspector(message); 
    foreach (IExposeDependencyInfo handler in handlers) 
    { 
        handler.ObtainDependencyDetails(inspector); 
    } 
    Approvals.Approve(message.ToString()); 
}

private static IHandler[] GetPotentiallyMisconfiguredComponents(WindsorContainer container) 
{ 
    var host = container.Kernel.GetSubSystem(SubSystemConstants.DiagnosticsKey) as IDiagnosticsHost; 
    var diagnostic = host.GetDiagnostic<IPotentiallyMisconfiguredComponentsDiagnostic>(); 
    var handlers = diagnostic.Inspect(); 
    return handlers; 
}

What’s important here is we’re setting up the container, getting the misconfigured components out of it, produce readable output from the list and passing it down to the approval framework to do the rest of the job.

Now if you’ve set up the framework to pup-up a diff tool when the approval fails you will be greeted with something like this:

You have all the power of your diff tool to inspect the change. In this case we have one new misconfigured component (HomeController) which has a new parameter, appropriately named missingParameter that the container doesn’t know how to provide to it. Now you either slap yourself in the forehead and fix the issue, if that really is an issue, or approve that dependency, by copying the diff chunk from the left pane to the right, approved pane. By doing the latter you’re notifying the testing framework and your teammates that you do know what’s going on and you know it’s not an issue the way things are going to work. Coupled with a sensible commit message explaining why you chose to approve this difference you get a pretty good trail of exception to the rule and reasons behind them.

That’s quite an elegant approach to a quite hard problem. We’re using it for quite a few things, and it’s been giving us really good value for little effort it took to write those tests, and maintain them as we keep developing the app, and the approved files change.

So there you have it, a new, useful tool in your toolbelt.

January 16, 2012

Lock-free thread safe initialisation in C#

I used to do quite a lot of concurrent programming early in my career. Recently I’ve been working again on optimising a large piece of code to behave better when ran in concurrent environment and I must share a secret with you – I had a great fun. It all started with a semi-serious challenge from a friend, and ended up consuming big part of my Christmas-new year break.

One of the problems I found, was that a group of objects that was being used on multiple threads had to be initialised in a thread safe manner – that is the initialisation code had to be ran just once, atomically, on a single thread. However afterwards it could be safely executed concurrently on multiple threads. This was being accomplished by using code similar to following:

public void Foo GetInitializedFoo()
{
   if(this.fooIsInitialized) return foo;
   lock(lockObject)
   {
      if(this.fooIsInitialized) return foo;
      
      InitializeFoo();
      return foo;
   }
}

As you can see the code usually works lock-free, and only the first time when foo is not initialised it has to lock to perform the initialisation algorithm. The reason that was suboptimal is that in heavily multi-threaded scenarios it yielded suboptimal performance when multiple threads were trying to initialise foo.

Imagine there are four threads. First of them succeeds in obtaining the lock, and goes ahead to perform the initialisation, while the other two go into the waiting queue and sleep there waiting for the lock to be freed. The first thread finishes the initialisation pretty soon, but by the time the first thread wakes up already quite a lot of time is wasted. Then the second thread obtains the lock, but the remaining two, even though the variable is already initialised and therefore safe to be read concurrently, still wait in the lock queue. The three remaining threads could execute all at once now, yet they will be woken up and executed each in turn.

Mad scientist solution

The problem was that using lock proved to be suboptimal for the problem at hand. To try to address this (and to make my inner geek happy) I decided to look at making this code perform better.

While .NET framework library has lots of synchronisation primitives none of them really seemed to be any better suited for the job then good old Monitor. I didn’t want to put waiting threads to sleep immediately, as this is quite an expensive operation (and so is waking them up back again), and the initialisation would usually be performed quite quickly. I also wanted all the waiting threads to be able to execute concurrently with no synchronisation after the first one of them finished initialisation. To accomplish this I came up with the following solution:

public sealed class ThreadSafeInit
{
	// We are free to use negative values here, as ManagedTreadId is guaranteed to be always > 0
	// http://www.netframeworkdev.com/net-base-class-library/threadmanagedthreadid-18626.shtml
	// the ids can be recycled as mentioned, but that does not affect us since at any given point in time
	// there can be no two threads with the same managed id, and that's all we care about
	private const int Initialized = int.MinValue + 1;
	private const int NotInitialized = int.MinValue;
	private int state = NotInitialized;

	public void EndThreadSafeOnceSection()
	{
		if (state == Initialized)
		{
			return;
		}
		if (state == Thread.CurrentThread.ManagedThreadId)
		{
			state = Initialized;
		}
	}

	public bool ExecuteThreadSafeOnce()
	{
		if (state == Initialized)
		{
			return false;
		}
		var inProgressByThisThread = Thread.CurrentThread.ManagedThreadId;
		var preexistingState = Interlocked.CompareExchange(ref state, inProgressByThisThread, NotInitialized);
		if (preexistingState == NotInitialized)
		{
			return true;
		}
		if (preexistingState == Initialized || preexistingState == inProgressByThisThread)
		{
			return false;
		}

		var spinWait = new SpinWait();
		while (state != Initialized)
		{
			spinWait.SpinOnce();
		}
		return false;
	}
}

The ThreadSafeInit class manages lock-free access to part of codebase. It has a state int flag which starts off in a non-initialised state. Then as ExecuteThreadSafeOnce method, which marks the beginning of the initialisation section is being called, it uses Interlocked.CompareExchange to set the flag in a lock-free thread safe manned to the id of current thread. The thread that succeeds returns true and is free to go ahead and do the initialisation. Any other thread waits for the first one to finish, but instead of going immediately to sleep it spins for a while, effectively wasting cycles, and then once the first thread finishes, and calls EndThreadSafeOnceSection method, all the other threads can proceed in parallel.

Usage pattern looks something like this:

public void Foo GetInitializedFoo()
{
   if(this.fooIsInitialized) return foo;
   var initialising = false;
   try
   {
      initializing = init.ExecuteThreadSafeOnce();
      if(this.fooIsInitialized) return foo;
      
      InitializeFoo();
      return foo;
   }
   finally
   {
      if(initialising)
      {
         init.EndThreadSafeOnceSection();
      }
   }
}

Using this code I was able to measure over two-fold improvement over the old solution in this part of code. Sure, it’s a micro-optimisation and in 99.9% of cases lock would be just fine, but as I said, it was a challenge, and I had a blast working on this, and that’s all I care about. Well, not all perhaps. If you see any flaws in this code, ways to improve it, or I just replicated something that someone else did much better long time ago, let me know.

January 5, 2011

C# dynamic and generics dispatch

I remember when C# 3 came out, I immediately started using pretty much all of the new features in it and I loved it. Imagine developing without var, automatic properties, lambdas, extension methods including those in .Linq namespace.

With C# 4 it’s been different. Even though it’s been several months since I started using Visual Studio 2010 and .NET 4, except for generic variance and occasional use of named arguments I hardly use any of the new features. Especially, I couldn’t find a good use case for the most hyped new feature – the dynamic keyword.

Until today, that is.

Short introduction to the problem

The application I’m working on right now, has forms (you wouldn’t expect that, would you?). Each of them collects some data in steps and based on answers from previous step, its own state etc, it decides whether or not it needs to collect more info or “does stuff”.

So the C# 3 version…

Each form (questionnaire) implements a common interface and various (multiple!) closed version of IHandleData<TData> interface for each type of data it collects from the user. The solution is very loosely generic, so the code that wires those things together does not know any details about the types it’s working with. All it knows is that it gets two objects – one of them is the data type, and the other implements generic IHandleData closed over the former type. It then has to somehow invoke the right one (of many) Handle method on the first object, passing the second one as the argument.

To handle this, we came up with code resembling the following (this code is simplified – the actual solution is a tad more elaborate):

var viewType = data.GetType();
var closedType = typeof(IHandleData<>).MakeGenericType(viewType);
var handle = closedType.GetMethod("Handle");
handle.Invoke(questionnaire, new[] { data });

There’s quite a lot of ceremony here, to work around the fact that at compile time we don’t have enough type information (and that type information are different from invocation to invocation) to satisfy the compiler.

Then again in C# 4…

In situations like this, involving generics and dynamic dispatch, you can leverage the new C# 4 capabilities, to make the code much neater and much more concise:

dynamic data = GetData();
dynamic questionaire = GetQuestionaire();
questionaire.Handle(data);

The additional benefit to vastly improved readability of the code is better performance. A useful thing to keep on the back of your head.

December 15, 2010

ConcurrentDictionary in .NET 4, not what you would expect

.NET 4 brings some awesome support for multithreaded programming as part of Task Parallel Library, Concurrent collections and few other types that live now in the framework.

Not all behaviour they expose is… not unexpected thought. What would be the result of the following code:

        
private static void ConcurrentDictionary()
{
	var dict = new ConcurrentDictionary<int, string>();
	ThreadPool.QueueUserWorkItem(LongGetOrAdd(dict, 1));
	ThreadPool.QueueUserWorkItem(LongGetOrAdd(dict, 1));
}
 
private static WaitCallback LongGetOrAdd(ConcurrentDictionary<int, string> dict, int index)
{
	return o => dict.GetOrAdd(index,i =>
										{
											Console.WriteLine("Adding!");
											Thread.SpinWait(1000);
 
											return i.ToString();
										}
					);
}

We call GetOrAdd method from ConcurrentDictionary<, > on two threads trying to concurrently obtain an item from the dictionary, creating it using provided delegate in case it’s not yet present in the collection. What would be the result of running the code?

Surprisingly both delegates will be invoked, so that we’ll see the message “Adding!” being printed twice, not once. This unfortunately makes the class unusable for a whole range of scenarios where you must ensure that creation logic is only ran once. One scenario where I wished I could use this class was Castle Dynamic Proxy and its proxy type caching. Currently it uses coarse grained double checked locking. The code could benefit from more elegant API like the one exposed by ConcurrentDictionary and fine grained locking.

However looks like ConcurrentDictionary is not an option, not unless coupled with Lazy<>, which while I suppose would work, is far less elegant and would not perform so good, since both classes would use their own, separate locking, so we’d end up using two locks instead of one, and having to go through additional, unnecessary layer of indirection.

So the message of the day is – new concurrent classes in .NET 4 are awesome but watch out for issues anyway.

August 6, 2010

On C# 4, co/contra-variance and generic constraints

While trying to clean up some code today, I stumbled upon interesting result of certain refactoring.

Given the following covariant interface and its implementation:

 
public interface IReference<out T> { }
public class ComponentReference<T> : IReference<T> { }

and the following usage:

public static IReference<IInterceptor> ForType<T>() where T : IInterceptor
{
    return new ComponentReference<T>();
}

the code won’t compile. However, not all is lost – if you cast explicitly, everything will work just fine:

public static IReference<IInterceptor> ForType<T>() where T : IInterceptor
{
    return (IReference<IInterceptor>)new ComponentReference<T>();
}

June 12, 2010

Thoughts on C# 4.0’ optional parameters

C# 4.0 is just round the corner and along with it set of nice new additions to the language, including optional parameters. There’s been some historical resistance to add this feature to the language, but here’ it is, and I’m glad it’s coming, or at least I was.

In few words, optional parameters, have their default value specified in the signature of the method. You can then skip them when calling method, and the method will be called with their default values.

So, what’s the deal?

To simplify the current discussion I will refer to the method containing default parameters (Foo in this example) as called method, and to method providing the default value (DateTime.Now getter in the example few paragraphs below) as value provider.

Take a look at the code below. Method Foo has two parameters, but we can call them as if it had none.

Looking good so far, right? Let’s take a look at how Main method looks like in Reflector.

As we can see there’s no magic here – simple compiler trick. Compiler binds the invocation to the method, and them puts the arguments for you. The code looks as if you had written it yourself in earlier version of C#.

Still good, right? So how does exactly the compiler knows what to put on the calling side? Let’s take a look at the compiled signature of the method Foo.

Ha! The values are encoded in DefaultParameterValueAttribute. Do you see the problem here? No? Than let’s try something else. Let’s change the signature of the method to take DateTime instead of int.

Notice we initialize the time to default value of DateTime.Now. All good? So let’s compile the code, shall we?

Oops.

Turns out we can’t. What seems like a really reasonable code is not allowed. Since the default values for arguments are being kept in attributes they must be a compile time constants, which includes primitive types (numeric types and strings), tokens ( typeof, methodof, which is not exposed in C# though ) and nulls. Pretty disappointing right? This means no new Foo(), no Foo.Bar is allowed. This dramatically limits the range of scenarios where this feature can be used, as most of the time, you’ll want not null, but something else as your default value, in which case you’ll end up creating overloads anyway.

There are some workarounds, like the one described in this book, but they have their own downsides, and it’s not always possible to use them anyway.

This all makes me think – why did the authors of the language decided to provide such crippled implementation of the feature? I’m not an expert in this matter, but I found a simple way in which the feature could be implemented allowing for far greater range of scenarios.

What if…

Let’s re-examine how this feature works.

The compiler puts the default values of the arguments in a special attribute type on the called method signature.
On the calling side, the compiler reads the values, and puts these of them that were not provided explicitly.

All the work happens at compile time (let’s ignore the dynamic for a moment, we’ll get to that as well) so no additional work at runtime is required. Since the compiler is very powerful, why not go one step further.

I think by simply extending this approach the following scenarios could be enabled.

using value returned by static parameterless method (this includes static property getters) as default value.
using value returned by instance parameterless method defined on the same type (or base type of the type) as called method is defined on (this would only be applicable for instance methods).
using default, parameterless constructors as default value.
or if we wanted to extend it further: using value returning by any variant of the above that does take parameters that are allowed to be put in the attribute (including both constants, and values of other parameters).

Let us examine how this could be (I think) achieved.

The spoon does not exist

What we would need is a way to store information which method, or constructor of which type we want to invoke in case no default value is provided. Since tokens are legal in attributes, the existing approach could be extended with something like this:

We have a way of storing the method. Now, the compiler could easily retrieve the token and invoke the called method.

If value provider is static there’s no problem – just call it, regardless of whether called method is an instance or static method.
If value provider is instance method, and called method is instance method as well, invoke the value provider on the instance on which called method is being invoked (hence the requirement that value provider must be declared on the same type as called method or its base type).
If value provider is instance method but called method is static do not allow (at compile time!) this code to compile, since there’s no instance to call the value provider on.

When it comes to constructors it is even simpler – since we allow only default constructor, at compile time we would check if the type does indeed have default, accessible constructor, and disallow the code to compile otherwise. Then when the called method is being invoked, retrieve the type token and call the default constructor on that type.

What about dynamic code?

I don’t have very intimate knowledge of dynamic code yet, but I think this could work with dynamic code as well. The compiler would put all the information on the call site (new concept introduced in .NET 4.0) and this would be all we need. In C# 1.0 having MethodInfo of a method you could invoke it. Same having System.Type it is easy to find and invoke it’s default constructor using little bit of reflection. I really see no reason why this would not work.

What do you think – am I missing part of the picture – is it something terribly wrong with my idea that would restrain it from working? Or maybe C# team didn’t really want (as they used to) implement this feature so they provided only the minimal implementation they needed for other major features, COM interop specifically.

Technorati Tags: C#

September 2, 2009

Solving a programming puzzle

My fellow devlicio.us blogger Tim Barcz posted an interesting problem to solve. I think it’s fun, so I decided to give it a try. Now, I don’t know enough context to solve it for just about any case (and I don’t think that’s even possible), so I made a few assumptions.

The strings we’re gonna be handling are not too long. Otherwise I’d probably use a StringReader/Writer.
I’m looking at minimal solution. YAGNI – I could do some optimizations probably, but I want to keep it simple, because the sample problem (just a handful of characters) is simple.
Solution is not context specific. In other words, if you want to swap characters differently based on context, it won’t do it. Again, I’m keeping it simple.
I’m using a factory here, to create the cleaner and feed it with mapping but based on the needs and tools available, I’d probably use an IoC container to get the instance, and if needed get the mapping from an external file, where it’s more readable, and can be easily changed.

Now, here’s the code:

public string CleanInput( string input )

    StringCleaner cleaner = CleanerFactory.BuildCleaner( input );

    return cleaner.Clean( input );

The CleanerFactory is not important. All it does is construct an instance of a StringCleaner and feed it with the mapping. However, I’ll post it for completeness:

public static class CleanerFactory

    public static StringCleaner BuildCleaner( string input )

        var cleaner = new StringCleaner();

        BuildMapping( cleaner );

        return cleaner;

    private static void BuildMapping( StringCleaner cleaner )

/*

         *  Character         Correct ASCII Value     Bad Values

            Hyphen             45                         8208, 8211, 8212, 8722, 173, 8209, 8259

            Single Quote     39                         96, 8216, 8217, 8242, 769, 768

            Double Quote     34                         8220, 8221, 8243, 12291

            Space             32                         160, 8195, 8194

*/

        cleaner.AddMapping( (char) 45, (char) 8208, (char) 8211, (char) 8212, (char) 8722, (char) 173, (char) 8209, (char) 8259 );

        cleaner.AddMapping( (char) 39, (char) 96, (char) 8216, (char) 8217, (char) 8242, (char) 769, (char) 768 );

        cleaner.AddMapping( (char) 34, (char) 8220, (char) 8221, (char) 8243, (char) 12291 );

        cleaner.AddMapping( (char) 32, (char) 160, (char) 8195, (char) 8194 );

The cleaner itself looks like this:

public class StringCleaner

        private IDictionary<char,char> mappings = new Dictionary<char, char>();

        public string Clean( string input )

            if( string.IsNullOrEmpty( input ) )

                return string.Empty;

            var buffer = new StringBuilder( input );

            for( int i = 0; i < buffer.Length; i++ )

                var character = buffer[i];

                char validCharacter;

                if( this.mappings.TryGetValue( character, out validCharacter ) )

                    buffer[ i ] = validCharacter;

            return buffer.ToString();

        public void AddMapping( char validValue, params char[] invalidValues)

            if( invalidValues == null )

                throw new ArgumentNullException( "invalidValues" );

            foreach( var invalidValue in invalidValues )

                this.mappings[ invalidValue ] = validValue;

Since strings are immutable, I’m using a StringBuilder to iterate over all the characters in the string, and replace these I want. I’m using Dictionary for the mapping, because it has a readable API, and O(1) search time.

August 10, 2009

WCF service host builder

When you have a WCF service that is not a singleton, and you want to use non-default constructor, you enter a world of pain. There’s a lot of hoops that you have to go through to plug an IInstanceProvider into the service. Even worse if you have many services. To alleviate the pain, I created a small helper method.

private ServiceHost GetService<TService>( string address, Func<TService> createServiceInstance )

    var service = new ServiceHost( typeof( TService ) );

    var serviceInstanceFactoryBehavior = new ServiceInstanceFactoryBehavior( () => createServiceInstance() );

    var endpoint = service.AddServiceEndpoint( typeof( TService ).GetInterfaces().Single(), this.GetBinding(), address );

    endpoint.Contract.Behaviors.Add( serviceInstanceFactoryBehavior );

    return service;

It is based on few assumptions:

All service types implement just one contract (which I think you should strive for anyway).
All services use the same binding.

ServiceInstanceFactoryBehavior plugs a custom IInstanceProvider into the host, that uses the provided delegate to fabricate new instances.

As a sidenote, Castle WCF integration facility can do this (in a much more flexible manner), but unfortunately we can’t use it.

Technorati Tags: WCF

July 23, 2009