Gendarme is a tool for analyzing and finding problems in code in ECMA CIL format (For MS only people out there that is the specification of which MSIL is an implementation). The tool itself comes with a boatload of useful rules to find problems in your code, one example of a rule is ProvideCorrectArgumentsToFormattingMethodsRule this makes sure that every time you call String.Format the number of arguments specified will correspond to the number specified in the format string:

string.Format("{0} would like a cup of {1}", "Jakob"); 

So the rule would find the above and report it to us when we run our assemblies through Gendarme with that rule chosen.  There are a wide array of rules available already but if you feel something is missing either because it is not yet included in Gendarme or perhaps its a rule very specific to a project your working on, you can easily add rules to the framework, that was what it was build for!

Gendarme uses Mono.Cecil to inspect the CLI Image, basically the same as Reflection in Microsoft’s BCL does, and furthermore supports modifying it as Reflection.Emit does. However Reflection and Reflection.Emit only expose a subset of the features of CLI Images whereas Mono.Cecil gives you full access. So the code we are using to inspect and check for our rules is similar in functionality to Reflection code as you know it from MS, however there are some differences.

The first thing to do is to write some tests for the rule we want to create. My idea for a rule is that I would like to avoid getters calling themselves which we all know often is a bad idea. So a simple test class to be used for testing this rule for both success and failures could look like this:

public class Item
{
    public bool UsesItSelf
    {
        get { return UsesItSelf; }
    }

    public bool DoesNotUseItSelf
    {
        get { return false; }
    }
}

Gendarme comes with a bunch of functionality for helping out testing rules in the form of some generic baseclass for our NUnit tests. In our case we want to create a MethodRule (as getters and setters are separate methods in CIL code). So we inherit from MethodRuleTestFixture<T> and get simple functionality to do Assertions on Success or Failure on applying our rule to specific methods. Confused, don't be the test cases are as simple as this:

[TestFixture]
public class UsePropertyGetterInPropertyGetterTest : MethodRuleTestFixture<UsePropertyGetterInPropertyGetterRule>
{
    [Test]
    public void TestUsesItSelf()
    {
        AssertRuleFailure<Item>("get_UsesItSelf");
    }

    [Test]
    public void TestDoesNotUseItSelf()
    {
        AssertRuleSuccess<Item>("get_DoesNotUseItSelf");
    }
}

The generic AssertRuleFailure and AssertRuleSucces takes a generic parameter that tells the type under test and the parameter tells which method should be called. When C# is compiled to CIL code the getters and setters are expanded to two methods with get_ and set_ prefixes in case you didn't know.

Next up we need to implement the actual rule as currently our test cases can't even compile. Our rule needs to be a MethodRule so we need to implement the IMethodRule interface from Gendarme, fortunately a base class called Rule exists which does a lot of the hard work for us already so we inherit from that as well.

[Problem("This property getter calls itself")]
[Solution("It is probably not supposed to, if it is consider refactoring to make it more readable")]
public class UsePropertyGetterInPropertyGetterRule : Rule, IMethodRule
{
    public RuleResult CheckMethod(MethodDefinition method)
    {
        if (!method.IsGetter)
            return RuleResult.DoesNotApply;

        if (!method.HasBody)
            return RuleResult.Success;
        foreach (Instruction instruction in method.Body.Instructions)
        {
            if (instruction.OpCode == OpCodes.Call)
            {
                if(instruction.Operand.ToString() == method.ToString())
                {
                    Runner.Report(method, Severity.High, Confidence.Total);
                    return RuleResult.Failure;
                }
                
            }
        }
        return RuleResult.Success;
    }
}

The only method we implement is CheckMethod, this is called when Gendarme finds a Method and our rule is enabled, so we get the MethodDefinition and need to return a RuleResult. So we take these steps:

1. We check if this is a Getter, if not our rule does not apply

2. We determine the rule it successful if nobody is available (No body = it doesn't call itself)

3. We loop through instructions in the method body and find out if a Call OpCode exists, if it does we compare the method being called with the method we are currently analyzing, if they are the same we return a failure and report this to the Gendarme Runner

That’s it, we have all green lights from our simple test case. We can now use it in the Gendarme tool, either command line, GUI or in your favorite build system. In case of command line usage (and UI I guess) you can add you own assembly containing your own rules to the rules.xml file found in the location you installed Gendarme.

As a last note I would really recommend that you look into the rules bundled with Gendarme, there are a lot of useful ones that could save you a lot of pain if you happen to not have perfect test coverage.

(Be aware that this is meant as an example only of implementing a rule in Gendarme, the above test suite is slim and the code for the actual rule uses some shortcuts that should be eliminated)

Currently I'm working with a system handling different operations when receiving business documents in object form. Its quite obvious that the code for handling this has evolved to have a lot more responsibilities than it was intended to.

So already having an Inversion of Control container in our stack I thought we could make the operations in the pipeline configurable using the container. To achieve this we need to specify an interface for the tasks in the pipeline, in our case its pretty simple:

public interface IPipelineTask<T>
{
    T Perform(T instance);
}

Secondly we need to define the pipeline itself, again using a generic interface:

public interface IPipeline<T>
{
    T Execute(T instance);
}

So basically what I want to accomplish is the ability to ask my Inversion of control container for a pipeline for a certain type and be able to call the Execute method on the instance and have all associated tasks performed on the instance I pass to the method. So the code for handling an incoming object of type Invoice would look like this:

Invoice incomingInvoice = ....;
ProjectContainer container = new ProjectContainer();
IPipeline<Invoice> pipeline = container.Resolve<IPipeline<Invoice>>();
Invoice processedInvoice = pipeline.Execute(incomingInvoice);
container.Release(pipeline);

So lets look at the implementation of the generic pipeline that handles executing of each task:

public class Pipeline<T> : IPipeline<T>
{
    private IPipelineTask<T>[] tasks;
    public Pipeline(IPipelineTask<T>[] pipelinetasks)
    {
        tasks = pipelinetasks;
    }

    public T Execute(T instance)
    {
        T processedInstance = instance;
        foreach (var task in tasks)
        {
            processedInstance = task.Perform(processedInstance);
        }
        return processedInstance;
    }
}

Note the constructor takes an array of IPipelineTasks<T> this is here our Inversion of Control container comes to play and does this for us using constructor dependency injection.

Each task needs to implement the IPipelineTask<T> with its specific business object type:

public class InvoiceNotifier : IPipelineTask<Invoice>
{
    private IUserNotifier usernotifier;
    public InvoiceNotifier(IUserNotifier notifier)
    {
        usernotifier = notifier;
    }

    public Invoice Perform(Invoice instance)
    {
        usernotifier.Notify(Notification.IncomingInvoice,
                            "The invoice with identifier " + instance.ID + " changed state to " + instance.State);
        return instance;
    }
}

Normally when working with arrays in Castle Windsor we have to specify each service to be part of the array in the configuration, however in our case we want all registered implementations of the specific interface to be passed to the pipeline. To do this we can add a custom sub dependency resolver to castle, in fact we can use the ArraySubDependencyResolver already written by Castle projects founder (and soon to be Microsoftee) Hammett. With this in place we can make the following configuration and our mission is accomplished and all tasks registered in the configuration will be injected when we request the generic Pipeline of this type.

<components>
   <!--Register the generic pipeline--> 
  <component
    id="bussiness.document.pipeline"
    service="Services.IPipeline`1, Services"
    type="Services.Pipeline`1, Services"
    lifetype="Thread"
    />
   <!--Register our pipeline tasks-->
  <component
    id="invoice.notification"
    service="Services.IPipelineTask`1[[Domain.Invoice, Domain]], Services"
    type="Services.InvoiceNotifier, Services"
    lifetype="Thread"
    />
  <component
    id="invoice.reciever"
    service="Services.IPipelineTask`1[[Domain.Invoice, Domain]], Services"
    type="Services.InvoiceReciever, Services"
    lifetype="Thread"
    />
  
   <!--Registration of services and repositories which our pipeline tasks uses-->
   ....
</components>

Using this infrastructure custom tasks can be specified easily in the configuration even from other namespaces and assemblies. And the pipeline doesn't need to worry about the dependencies of each Pipeline task, the container handles this

When working with object relational mapping(or even handrolled DAL's) you most often work on fully populated objects. When working in an environment utilizing Data Transfer Object either for transport over the wire or screen bound  DTO's you have to slice or merge your fully populated objects. With LINQ for nHibernate, LINQ for SQL the solution for this is pretty obvious you populate the object using its constructor or object initialisers  in a LINQ query either directly on your data source or on one or more already populated instances.

A quick example using LINQ for nHibernate could be:

var result = from p in db.Products select new ProductDTO {p.ID, p.Name} ;

(Of course we need to make instances not anonymous types because we need to pass them out of the current scope)

If we are stuck using traditional querying in nHibernate we can accomplish the same using HQL:

select new ProductDTO(p.ID, p.Name) from Product p

When using this HQL query its important to remember to import your DTO class in the mapping or else you will end up with an error like:

NHibernate.QueryException : class not found: ProductDTO

To import it just add <import class="Name.Space.ProductDTO, Assembly"> right after your hibernate-mapping element. Of course the generating of the DTO's can get much more complex than the samples i have shown. They could span multiple business object requiring complex queries but the concept remains the same.

Okay, so these options are valid only for folks using an LINQ empowered ORM's or frameworks with equivalent functionality to the nHibernate sample above. One thing we could do is to create the DTO's from the fully populated objects. Of course this could be a dangerous decision if you don't already have the objects in the current context and the DTO's require a very little subset of the data, so that's definitely worth noting. That beeing said we could do this in a number of ways all which i can thing of writing myself involves plumbing code. So a couple of days ago I stumbled upon a project called otis a object transformer or Object-to-Object mapper if you prefer that term.

The concept is pretty simple, we can define how one object map to another so if we take our very simple case we can specify a mapping on this form:

<?xml version="1.0" encoding="utf-8" ?>
<otis-mapping xmlns="urn:otis-mapping-1.0">
  <class name="Name.Space.ProductDTO, Assembly" source="Name.Space.Product, Assembly" >
    <member name="ID" />
    <member name="Name" />
  </class>
</otis-mapping>

In the above case we have the same names on properties in both classes so its pretty simple, but the possibilities in the mapping is many. You can use expression to combine multiple values to one, projections, exchanging certain values etc. I will certainly have to look into the source code of otis and have a look of its capabilities as the documentation is a bit sparse.

To utilize the above mapping we configure the framework and use a generic class to get Assembler classes that can convert our types, its pretty simple:

Product product = ...; //Our fully populated product instance
Otis.Configuration conf = new Otis.Configuration();
//Looks for embedded ressource with *.otis.xml ending
conf.AddAssemblyResources(Assembly.GetExecutingAssembly(), "otis.xml"); 
//Declare our assembler
var asm = conf.GetAssembler<ProductDTO, Product>();
//Use the assembler to get the DTO
ProductDTO dto = asm.AssembleFrom(product);

As I said I will definitely dive into the source to explore which features are available and how the transformation is done and what the costs of it is. The main issue I have with the approach is that we could do the same using code and to make it more flexible lambda expressions and have it strongly typed and avoid the verbosity of XML, but lets see how feature rich Otis is before dismissing it.

A .NET User Group is starting up in Copenhagen for more information check http://cnug.dk/ (in Danish). I Hope to see many of the Danish developers on the 19th of June in Ballerup. Its gonna be a talk about expectations for the User Group and a presentation of some concepts from object relational mapping.

Notice that the scrollbar isn't at the bottom. That's a lot of data to fetch if you only show a single page of them