Getting aspect oriented programming (AOP) working with objects in Spring.NET using the IoC container's XML configuration takes some concentration, since there's plenty going on--from defining the pointcut to coding up the advice to preparing the object factory that wraps the target in a proxy. 

Below is a relatively concise XML configuration to do all of these things:

    <object id="MyPointcutAdvisor" type="Spring.Aop.Support.NameMatchMethodPointcutAdvisor, Spring.Aop">
        <property name="Advice">
            <object type="{ your interceptor type goes here, e.g. something that implements IMethodInterceptor }"/>
        </property>
        <property name="MappedNames">
            <list>
                <value>{ specify a method name to intercept here } </value>
                <value>{ specify a method name to intercept here } </value>
            </list>
        </property>
    </object>
    <object id="MyProxy" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
        <property name="Target">
            <object type="{ the wrapped target type goes here }"/>
        </property>
        <property name="InterceptorNames">
            <list>
                <value>MyPointcutAdvisor</value>
            </list>
        </property>
    </object>

Note that you can change NameMatchMethodPointcutAdvisor to something more robust like RegularExpressionMethodPointcutAdvisor if you need to intercept methods based on regular expressions rather than simple names.

To get a reference to the proxy object with advice in place, use ref="MyProxy" in the configuration XML for IoC hookup, or use this code:

You can also wrap a pre-instantiated object at runtime:

Important note:  Spring.NET proxies use a decorator (inheritance) pattern or a composition pattern.  Neither approach allows advice on methods that are not interface implementations and not virtual!  Further, Spring.NET will not warn you or give you an error if it cannot configure advice for a non-virtual, non-interface method; instead, the methods will simply not be intercepted, leading to sometimes confusing bugs.  This issue is documented on the Spring.NET forums and bug tracker.

The decorator (inheritance) pattern is used when the target being proxied has no interfaces to proxy or ProxyTargetType is set to true on the proxy factory.  In this case the target type is subclassed and contains an internal pointer to the target object.  Otherwise the composition pattern is used, where a new class is defined dynamically implementing all the interfaces and likewise contains an internal pointer to the target object.

Spring.NET 1.1 makes managing transactions straightforward with the TransactionAttribute attribute.  For example:

The details of what this means and how this works is fully documented.

It works great when you're using IoC features to configure objects.  But what if you want to slap TransactionAttribute on methods of classes you haven't pre-configured and whose lifetime you do not control, say for a methods on a unit test class (i.e. one with a [TestClass] attribute)? 

You can easily get the same kind of support by 1) defining a placeholder object in the Spring configuration, and 2) wrapping objects in proxies on the fly using this placeholder name.

Step 1:  Define a placeholder object

The configuration XML to get transaction attributes to work is a bit, well, verbose, as you can see below.  The red text shows the additions you can add to define a placeholder object called TransactionSupportedType.  You can use any name you wish.  The configuration basically says "objects named TransactionSupportedType should have methods with the TransactionAttribute intercepted."

    <!-- DAO -->
    <object id="Dao"
            type="TestApp.HibernateDao, TestApp"
            singleton="true">
        <property name="SessionFactory" ref="SessionFactory"/>
    </object>

    <!-- Transaction manager -->
    <object id="TransactionManager"
            type="Spring.Data.NHibernate.HibernateTransactionManager, Spring.Data.NHibernate12">
        <property name="DbProvider" ref="Provider"/>
        <property name="SessionFactory" ref="SessionFactory"/>
    </object>

Step 2:  Wrap objects in proxies on the fly

Here's where we can easily leverage the AOP engine of Spring.NET to build the proxy we need-on-the fly.  It's as simple as:

This configures the preexisting object of type MyType with the configuration of TransactionSupportedType.  The proxy's public methods with the TransactionAttribute specified will be intercepted appropriately.  Be aware of an important gotcha:  the attribute works with public and/or interface methods only; you cannot use it with protected methods, even if they are marked virtual.  Advice on protected virtual methods may be available in Spring.NET 1.2 where in addition to composition and decorator proxies, inheritance proxies will be supported.