How to set the current culture in NServiceBus

2011-03-21 by mookid8000 3 Comments

Today we were experiencing some weird behavior when running an integration test with DillPickle, where – apparently – values of doubles would lose their decimal point when they were transferred in messages from our test to an NServiceBus service.

Stopping the service and inspecting the message in the queue quickly revealed a message that looked somewhat like this:

<Messages>
    <SetCurrentValueMessage>
        <Value>13.56</Value>
    </SetCurrentValueMessage>
</Messages>

</SetCurrentValueMessage>

</Messages>

which is all fine and dandy.

Now, I’m used to being Danish, so I know that we’re somewhat deviant in regards to our decimal point – “,” – so we quickly diagnosed the problem: Our integration tests were running with the invariant culture, to allow us to parse Gherkin files in English and use “.” as the decimal point – but Windows and everything else was running with da-DK, so 13.56 would be improperly deserialized to the value 1356 when it reached our NServiceBus service.

Solution: Normalize the culture of all the processes of our system.

Our first attempt was to modify the culture in our endpoint configuration like so:

public class EndpointConfiguration : IConfigureThisEndpoint, AsA_Server
{
    public EndpointConfiguration()
    {
        // does NOT work!
        Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
        Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;
    }
}

public class EndpointConfiguration : IConfigureThisEndpoint, AsA_Server

{

public EndpointConfiguration()

{

// does NOT work!

Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;

Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;

}

but obviously this did not work, because NServiceBus does not deserialize messages on this thread!

Our solution was to create a message module, which seems to get called before transport messages are deserialized, setting the culture in there – like so:

public class SetCurrentCultureMessageModule : IMessageModule
{
    public void HandleBeginMessage()
    {
        // works!
        Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
        Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;
    }

    public void HandleEndMessage()
    {
    }

    public void HandleError()
    {
    }
}

public class SetCurrentCultureMessageModule : IMessageModule

{

public void HandleBeginMessage()

{

// works!

Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;

Thread.CurrentThread.CurrentUICulture = CultureInfo.InvariantCulture;

}

public void HandleEndMessage()

{

}

public void HandleError()

{

}

In the future I’ll make sure that the culture is explicitly set in all processes of systems I am building. It’s kind of scary that errors could happen where stuff like “debit account 100.00” could be mis-interpreted as “debit account 10000”!! 😮

Little nifties #1

2011-03-18 by mookid8000 Leave a comment

Almost always, the first extensions methods I add to a system are these:

public static class EnumerableExtensions
{
    public static string JoinToString<T>(this IEnumerable<T> enumerable, Func<T, object> selector, string separator)
    {
        return enumerable.Select(selector).JoinToString(separator);
    }

    public static string JoinToString<T>(this IEnumerable<T> enumerable, Func<T, object> selector)
    {
        return enumerable.Select(selector).JoinToString(", ");
    }

    public static string JoinToString(this IEnumerable enumerable, string separator)
    {
        var strings = enumerable.Cast<object>()
            .Select(e => e == null ? "(null)" : e.ToString())
            .ToArray();

        return string.Join(separator, strings);
    }
}

public static class EnumerableExtensions

{

public static string JoinToString<T>(this IEnumerable<T> enumerable, Func<T, object> selector, string separator)

{

return enumerable.Select(selector).JoinToString(separator);

}

public static string JoinToString<T>(this IEnumerable<T> enumerable, Func<T, object> selector)

{

return enumerable.Select(selector).JoinToString(", ");

}

public static string JoinToString(this IEnumerable enumerable, string separator)

{

var strings = enumerable.Cast<object>()

.Select(e => e == null ? "(null)" : e.ToString())

.ToArray();

return string.Join(separator, strings);

}

which allows me to format any sequence of stuff sensibly, easily, and inline, e.g. like so:

Log.WarnFormat("Some stuff happened to stuff with these names: {0}", names.JoinToString(", "));

1	Log.WarnFormat("Some stuff happened to stuff with these names: {0}", names.JoinToString(", "));

and so:

Log.WarnFormat("Some stuff happened to things with these names: {0}", things.JoinToString(t => t.Name));

1	Log.WarnFormat("Some stuff happened to things with these names: {0}", things.JoinToString(t => t.Name));

and so:

catch(ReflectionTypeLoadException exception)
{
    Log.ErrorFormat(@"ZOMG!!111something happened!!


{0}", exception.LoaderExceptions.JoinToString(Environment.NewLine));
}

catch(ReflectionTypeLoadException exception)

{

Log.ErrorFormat(@"ZOMG!!111something happened!!

{0}", exception.LoaderExceptions.JoinToString(Environment.NewLine));

}

Nifty!

Tell, Don’t Ask

2011-03-07 by mookid8000 Leave a comment

or “How big is an interface?”… Uuuh, what?

Well, consider these two interfaces:

public interface ISomeService1
{
    void SetStuff(double value);
    void SetSomeOtherStuff(string anotherValue);
    void SetMoreStuff(bool moreStuff);
    void SetEvenMoreStuff(bool eventMoreStuff);
}

public interface ISomeService2
{
    SomeValue GetValue();
}

public interface ISomeService1

{

void SetStuff(double value);

void SetSomeOtherStuff(string anotherValue);

void SetMoreStuff(bool moreStuff);

void SetEvenMoreStuff(bool eventMoreStuff);

}

public interface ISomeService2

{

SomeValue GetValue();

}

– which is bigger?

If you think that ISomeService1 is the bigger interface, then there’s a good chance you’re wrong! Why is that?

It’s because an interface is not just the signatures of the methods and properties it exposes, it also consists of the types that go in and out of its methods and properties, and the assumptions that go along with them!

This is a fact that I see people often forget, and this is one of the reasons why everything gets easier if you adhere to the Tell, Don’t Ask principle. And by “everything”, I almost literally mean “everything”, but one thing stands out in particular: Unit testing!

Consider this imaginary API:

public interface ISomeKindOfValueStore
{
    Values GetValues(string name); 
}

public interface ISomeKindOfValueStore

{

Values GetValues(string name);

}

Now, in our system, on various occasions we need to change the values for a particular name. We start out by doing it like this:

public class BusinessLogic
{
    ISomeKindOfValueStore someKindOfValueStore;
    public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore)
    {
        this.someKindOfValueStore = someKindOfValueStore;
    }

    public void Run()
    {
        var values = someKindOfValueStore.GetValues("MegaCorp");

        values.Value1 = 2.3; //< secret biz constants
        values.Value2 = 4.5;

        // more logic in here
    }
}

public class BusinessLogic

{

ISomeKindOfValueStore someKindOfValueStore;

public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore)

{

this.someKindOfValueStore = someKindOfValueStore;

}

public void Run()

{

var values = someKindOfValueStore.GetValues("MegaCorp");

values.Value1 = 2.3; //< secret biz constants

values.Value2 = 4.5;

// more logic in here

}

Obviously, if GetValues returns a reference to a mutable object, and this object is the one kept inside the value store, this will work, and the system will chug along nicely.

The problem is that this has exposed much more than needed from our interface, including the assumption that the obtained Values reference is to the cached object, and an assumption that the Value1 and Value2 properties can set set, etc.

Now, imagine how tedious it will be to test that the Run method works, because we need to stub an instance of Values as a return value from GetValues. And when multiple test cases need to exercise the Run method to test different aspects of it, we need to make sure that GetValues returns a dummy object every time – otherwise we will get a NullReferenceException.

Now, let’s improve the API and change it into this:

public interface ISomeKindOfValueStore
{
    void SetValues(string name, double newValue1, double newValue2); 
}

public interface ISomeKindOfValueStore

{

void SetValues(string name, double newValue1, double newValue2);

}

adhering to the “Tell, Don’t Ask” principle, allowing a potential usage scenario like this:

public class BusinessLogic
{
    ISomeKindOfValueStore someKindOfValueStore;
    public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore)
    {
        this.someKindOfValueStore = someKindOfValueStore;
    }

    public void Run()
    {
        someKindOfValueStore.SetValues("MegaCorp", 2.3, 4.5);

        // more logic in here
    }
}

public class BusinessLogic

{

ISomeKindOfValueStore someKindOfValueStore;

public BusinessLogic(ISomeKindOfValueStore someKindOfValueStore)

{

this.someKindOfValueStore = someKindOfValueStore;

}

public void Run()

{

someKindOfValueStore.SetValues("MegaCorp", 2.3, 4.5);

// more logic in here

}

As you can see, I have changed the API from a combined query/command thing to a pure command thing which appears to be much cleaner to the eye – it actually reveals exactly what is going on.

And testing has suddenly become a breeze, because our mocked ISomeKindOfValueStore will just record that the call happened, allowing us to assert it in the test cases where that is relevant, ignoring it in all the other test cases.

Another benefit is that this coding style lends itself better to stand the test of time, as it is more tolerant to changes – the implementation of ISomeKindOfValueStore may change an in-memory object, update something in a db, send a message to an external system, etc. A command API is just easier to change.

Therefore: Tell, Don’t Ask.