For more details and screenshots of Project Linker, please refer to this MSDN article.

Let’s go, step by step instructions:

1. Go to Extension Manager in VS 2010 and search for Project Linker.
2. Install Project Linker extension
3. Create new solution, say Castle.Core-SL
4. Add to this solution the existent Castle.Core project (targeted for NET 4 Client Profile)
5. Add to solution new Silverlight 4 project, named Castle.Core-SL
6. Click on Castle.Core-SL project and from context menu choose “Add project link…”
7. In “Select Source Project” dialog choose the Castle.Core project, click OK.
8. To verify that projects are linked correctly, in VS Project menu choose “Edit links”: Source Project should be set to “Castle.Core”, and Target Project – “Castle.Core-SL”.
9. In order to trigger real linking process (Project Linker is observing file changes in source project) I have a trick for you. Go to Castle.Core project, then select all folders containing source files (Components.DictionaryAdapter, Core and DynamicProxy) and click on “Exclude from project” in context menu. Then, after enabling “Show all files” options, add them back. Here Project Linker will kick in and will link all added source files to Target Project.

Then, we can do the same for project containing unit tests.

In case of Castle.Core there is another manual intervention required: filter out CastleBuild.snk file from being linked. To do that you have to open project file for your project and find an attribute in it called ProjectLinkerExcludeFilter. Add to the end of that value the string “;\.snk”. After that you should “Ad As Link” the key file manually.

If you want to “re-sync” both projects, you have to repeat only the 9th step.

Now, you’ll have your Castle.Core targeted to Silverlight with all source files from original .NET project. You’re now should be confortable enough exploring the code in Visual Studio and, why not, contribute…

In code, it looks like this:

  1: [Transactional]

  2: public class Foo

  3: {

  4:     [Transaction]

  5:     public virtual void Bar()

  6:     {

  7:         // Do something in a transaction

  8:     }

  9: }

 10: 

Let’s suppose that later, we want to test this code. Say, we want to verify that code in Foo.Bar() method is executed in a transaction. Moreover, we want to assure that the marking attributes will not be deleted accidentally.

We can test that within two aspects. First – an integration test: a real application part will be spawned and a call will be performed. After, we should verify that changes was committed by transaction. It takes time to run such a test (integration test usually runs slower) and effort to write & verify such a test. Second way to test that – is to check presence or required attributes. This will be a fast unit test that will just check that attribute is still applied to a method.

Those methods complements each other. Ideally, it should be both written.

Let’s see how we can verify that attributes required by ATM are applied to required methods.

First, we’ve defined the API that we want to use to do our check:

  1: CustomAssertions.ShouldUseATM<Foo>(foo => foo.Bar());

Yes, you see it right, we want to make it type save, refactor-able and nice looking.

This helper class should verify next assumptions, all required by ATM:

• Tested class should be marked with TransactionalAttribute;
• Method should be marked by TransactionAttribute;
• Method should be virtual.

Solution we came to this problem is the next class:

  1: public static partial class CustomAssertions

  2: {

  3:     public static void ShouldUseATM<T>(Expression<Action<T>> methodExpression) where T : class

  4:     {

  5:         ThrowIfTypeNotMarkedAsTransactional(typeof (T));

  6:

  7:         var methodInfo = ((MethodCallExpression) methodExpression.Body).Method;

  8:

  9:         ThrowIfMethodIsNotMarkedWithTransactionAttribute(methodInfo);

 10:         ThrowIfMethodMarkedWithTransactionAttributeIsVirtual(methodInfo);

 11:     }

 12:

 13:     private static void ThrowIfTypeNotMarkedAsTransactional(Type classType)

 14:     {

 15:         object[] foundAttributes = classType.GetCustomAttributes(typeof (TransactionalAttribute), false);

 16:         if (foundAttributes.Length == 0)

 17:             Assert.Fail("The type '{0}' is not marked with [Transactional] attribute", classType.Name);

 18:     }

 19:

 20:     private static void ThrowIfMethodIsNotMarkedWithTransactionAttribute(MethodInfo info)

 21:     {

 22:         var found = info.GetCustomAttributes(typeof (TransactionAttribute), false);

 23:         if (found.Length == 0)

 24:             Assert.Fail("Method '{0}' from '{1}' type is not marked with [Transaction] attribute",

 25:                         info.Name,

 26:                         info.DeclaringType.Name);

 27:     }

 28:

 29:     private static void ThrowIfMethodMarkedWithTransactionAttributeIsVirtual(MethodBase methodInfo)

 30:     {

 31:         if (methodInfo.IsVirtual && !methodInfo.IsFinal)

 32:             return;

 33:

 34:         Assert.Fail("Method '{0}' from '{1}' type is marked with [Transaction] attribute, but is not declared as virtual.",

 35:                     methodInfo.Name,

 36:                     methodInfo.DeclaringType.Name);

 37:     }

 38: }

 39: 

So far, we’re pleased with how it works for us.

One of those tricky places is his configuration system. To start use NServiceBus you have to do few steps to properly configure it. You have to use 2-3 “app.config” configuration sections with approximately 10-15 various parameters and few configuration classes provided by NServiceBus.

Another place that make me stuck is his integration with IoC (Inversion of Control) container. It has an abstraction over all container stuff, so you can pretty easily create an adapter to use it with container of your choice. I don’t like how this abstraction is used and implemented, a bit unnatural for my habits on how to put container to work.

Anyway, we have to deal with it, and use the NServiceBus with Castle Windsor container. As I said to do that you have to create an adapter for IBuilder interface. The NServiceBus Contrib project contains a patch that do this, but it is done in a completely wrong way – by mimicking the adapter for Spring framework. Bad, bad, bad…

So let’s take our big gun – Binsor from Rhino.Tools (I wrote about here) that should do all dirty work by configuring NServiceBus and integrating it in our existing Windsor container. The link to VS solution with all code shown here is provided at the end of the page.

Here we go – how to configure a subscriber for Pub/Sub interactions:

1. Binsor configuration (.boo file):

import System.Reflection
import NServiceBus
import NServiceBus.Unicast
import NServiceBus.Serialization
import NServiceBus.Serializers.Binary
import NServiceBus.Unicast.Transport
import NServiceBus.Unicast.Transport.Msmq
import NServiceBus.Unicast.Subscriptions
import NServiceBus.Unicast.Subscriptions.Msmq

import ObjectBuilder
import nServiceBus.CastleIntegration

component IBus, NServiceBus.Unicast.UnicastBus:
    MessageOwners = {"Messages":"messagebus"}
    MessageHandlerAssemblies = [Assembly.Load("Subscriber1")]

component ITransport, MsmqTransport:
    InputQueue = "worker"
    ErrorQueue = "error"
    NumberOfWorkerThreads = 1
    MaxRetries = 5
    IsTransactional = false
    PurgeOnStartup = false

component IMessageSerializer, MessageSerializer
component IBuilder, Builder

2. Program initialization:

var container = new WindsorContainer();

BooReader.Read(container, "nServiceBus.boo");

container.Register(SagasAndMessageHandlers.From(typeof(EventMessageHandler).Assembly));

var bus = container.Resolve<IBus>();

bus.Start();

That’s all. Now you can start send/receive messages.

For my taste this is much more readable and maintainable than traditional NServiceBus configuration. Less code, no XML, much cleaner, container friendly.

To make this work you have need for adapter class itself. His responsibility is to forward IBuilder.Build<T> calls to Castle’s Resolve<T> methods. Also, a small helper class that will register Sagas and MessageHandlers in container. Here it is:

public static class SagasAndMessageHandlers
{
    public static IRegistration[] From(params Assembly[] assemblies)
    {
        var registrations = new List<ComponentRegistration>();
        foreach (var assembly in assemblies)
        {
            var types = assembly.GetTypes();
            foreach (var type in types)
            {
                var implementedInterfaces = type.GetInterfaces();
                foreach (var interf in implementedInterfaces)
                {
                    if (!interf.IsGenericType)
                        continue;
                    var genericArguments = interf.GetGenericArguments();
                    if (genericArguments.Length != 1)
                        continue;

                    if (!typeof(IMessage).IsAssignableFrom(genericArguments[0]))
                        continue;

                    var sagaHandlerType = typeof(ISaga<>).MakeGenericType(genericArguments[0]);
                    if (sagaHandlerType.IsAssignableFrom(interf))
                    {
                        registrations.Add(CreateRegistration(type, sagaHandlerType));
                        registrations.Add(CreateRegistration(type, type));
                    }

                    var messageHandlerType = typeof (IMessageHandler<>).MakeGenericType(genericArguments[0]);
                    if (messageHandlerType.IsAssignableFrom(interf))
                        registrations.Add(CreateRegistration(type, type));
                }
            }
        }
        return registrations.ToArray();
    }

    private static ComponentRegistration CreateRegistration(Type type, Type handlerType)
    {
        string componentName;
        if (type == handlerType)
            componentName = type.FullName;
        else
            componentName = type.FullName + handlerType.FullName;

        return (ComponentRegistration)Component
                                          .For(handlerType)
                                          .ImplementedBy(type)
                                          .LifeStyle.Is(LifestyleType.Transient)
                                          .Named(componentName);
    }
}

One thing to notice here, NServiceBus required that a saga to be registered as a saga handler ( ISaga<Message>) and as a Saga class itself. A better way will be to use Castle’s newly added forwarding ability, when a component implementation can be accessed through multiple interfaces all forwarded to component’s instance. Bud I had no time to play with this feature yet, so this duplication will still here some time given the fact that no bugs showed up.

You can download a Visual Studio solution with all code shown here from this place. It contains all infrastructure code and two working sample projects ported from original NServiceBus samples – Pub/Sub & Saga.

Can_resolve_all_services_in_container()

Bill Simser wrote some time ago about the first test to be written when using Castle’s Windsor Container. It’s a real gem that let’s you verify if any of services registered in container can be resolved (have all required dependencies). Here is it, a bit improved for skipping verification for generic types, since, at that moment, we don’t know the generic argument for type to be constructed:

[Test]
public void Can_resolve_all_services_in_container()
{
    var container = new WindsorContainer("container.xml");
    foreach (IHandler handler in container.Kernel.GetAssignableHandlers(typeof(object)))
    {
        if (handler.ComponentModel.Service.IsGenericType)
            continue;

        container.Resolve(handler.ComponentModel.Service);
    }
}

Can_compile_NHibernate_mapping_configuration()

This test was sitting for a long time in our codebase, but I’ve seen it recently in this post of David Larebee. I wrote it in times when writing our first mappings and the only one way to verify if you don’t have any faults was to write one of CRUD operations and run the test. But that’s a long process. Shorter response cycle is always better. Here it is:

[Test]
public void Can_compile_NHibernate_mapping_configuration()
{
    ISessionFactory factory =
        new Configuration()
            .Configure()
            .AddAssembly("MyApp.MyDomainAssembly")
            .BuildSessionFactory();

    Assert.IsNotNull(factory);
}

This test suppose that you have HNibernate configuration in your app.config and tries to register all mappings from given assembly file.