# Saturday, July 17, 2004

I have freshened up the NCover project to build a simple Gui around it. Not much work, just some Category attributes to put there and there...

posted on Saturday, July 17, 2004 12:00:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]
# Friday, July 16, 2004

This blog presents an implementation of an Ant Colony Optimization (ACO) framework using Visual C# 2005 Express.

What is ACO ?

ACO is the evolution of the Ant Algorithms, algorithms that were based on observation on ants. It is a metaheuristic algorithm that is used to solve complex problems (NP-hard) such as the Travelling Salesman Problem(in this problem, a salesman has to travel across each city in a minimum distance). There is a lot of litterate on ACO and TSP on the web...

Where does it come from ?

My implementation is based on the book Ant Colony Optimization from Marco Dorigo. I must say that the authors have takened care of giving clear and well-detailled pseudo-code to make an implementation easy.

The first results

Here are some outputs of the TSP computation of burma14 using my framework. The red line represents the best-so-far solution, the other lines are colored with respect to their pheromone intensity.

  • Iteration 1:
  • Iteration 7:
  • Iteration 28:
  • Iteration 33:
  • Iteration 54:

Download

The download called MetaHeuristics is available at http://www.codeplex.com/metaheuristics .

posted on Friday, July 16, 2004 3:37:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [8]
# Thursday, July 15, 2004

This tutorial shows the basic usage of NCover from GotDotNet. The tutorial starts by creating a toy solution, how to set-up NCover execution, analysis and improvements of the results.

A toy solution

  1. Create a new solution,
  2. Add a C# assembly project named UnderCover,
  3. Add a class JamesBond defined as follows:
    using System;
    namespace UnderCover
    {
        public class JamesBond
        {
            public void Covered()
            {
                Console.WriteLine("Covered");
            }
            public void UnCovered()
            {
                Console.WriteLine("UnCovered");
            }
        }
    }
  4. Add a C# console application project name UnderCover.Console.exe
  5. Edit the Main entry method as follows:
    using System;
    namespace UnderCover.Cons
    {
        class Class1
        {
            [STAThread]
            static void Main(string[] args)
            {
                JamesBond james = new JamesBond();
                james.Covered();
            }
        }
    }
  6. Compile in debug mode
    Note: NCover needs the symbol files (.mdb) in order to work, so you need to work with the debug version.

Our objective is now to compute the coverage of UnderCover.dll when UnderCover.Console.exe is executed. It is straightforward to see that JamesBond.Covered will be fully covered while JamesBond.UnCovered will be not covered.

Setting a NCover batch file

In this step, we create a simple batch file in the bin/debug directory to execute NCover.Console.exe with the command line. The NCover command line takes the command line to execute + the assembly to cover as parameters:

"C:\Program Files\NCover\NCover.Console.exe" /c "UnderCover.Cons.exe" "UnderCover.dll" /v

The output of NCover is as follows

"C:\Program Files\NCover\NCover.Console.exe" /c "UnderCover.Cons.exe" "Under
Cover.dll" /v
NCover.Console v1.3.3 - Code Coverage Analysis for .NET - http://ncover.org

Command: UnderCover.Cons.exe
Command Args: UnderCover.dll
Working Directory:
Assemblies:
Coverage File:
Coverage Log:
******************* Program Output *******************
Covered
***************** End Program Output *****************
Copied 'C:\Program Files\NCover\Coverage.xsl' to '...\Coverage.xsl'

If everything executed correctly, a Coverage.xml and Coverage.xsl has appeared in the directory.

First look at the results

Open Coverage.xml in your browser and you will get something like this:

The coverage has worked, we have the expected results.

Better XSLT template

Now, this works fine for a simple assembly but the files becomes huge if you have a normal project so we need a better XSLT template. MbUnit has it's own NCover Coverage.xsl template (that you can get here) that supportes expand/collapse and computes the percents of coverages. Let us copy the new coverage.xsl to the directory:

Now this looks much better :)

Results in Reflector

As I showed in a previous post, the Reflector Code Coverage Addin can help you visualize the coverage in a more intuitive way. The steps to follow are:

  1. Add Reflector.TreeMap.dll as a Addin of Reflector,
  2. Load UnderCover.dll,
  3. Right-click on UnderCover assembly and choose Coverage TreeMap,
  4. Right-click on the TreeMap and load the Coverage.xml file
  5. Enjoy the results:

Downloads:

The solution of this tutorial is available in the download section of www.dotnetwiki.org .

posted on Thursday, July 15, 2004 10:54:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [13]

Just loaded the MbUnit solution in Visual C# Express 2005 and.... it worked without a single problem! Looks like we will have MbUnit for .NET 2.0 in the next release :)


posted on Thursday, July 15, 2004 6:04:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]

The MbUnit Console Runner Application has undergone a major "plastic surgery" to prepare the next release of MbUnit. The new features are :

  • Report output to Xml, Html or Text, or a combination of those. The output directory of the reports can also be specified in the command line,
  • Filtering of the fixture by
    • Namespace,
    • Type full name,
    • Category,
    • Author name,
    • Importanc
  • Each of the filter can be multiple, i.e. you can filter multiple namespace. The different filters are combined using a AND operator.
  • The help is showed each time it is called (I have copy/pasted) the output of
  • The parsed parameters are displayed before testing starts to give you more information, 

The output of console runner as it is in the CVS:

MbUnit 2.15.1657.17890 Console Application
Author: Jonathan de Halleux
Get the latest at   http://mbunit.tigris.org
------------------------------------------
    /report-folder:                     short form /rf  Target output folder for the reports
    /report-type:{Xml|Html|Text}        short form /rt  Report types supported: Xml, Html, Text
    /filter-category:                   short form /fc  Name of the filtered category
    /filter-author:                     short form /fa  Name of the filtered author name
    /filter-type:                       short form /ft  Name of the filtered type
    /filter-namespace:                  short form /fn  Name of the filtered namespace
    /verbose[+|-]                       short form /v   Return a lot of information or not...
    @file                             Read response file for more options
    files
------------------------------------------
-- Parsed Arguments
Files:
        MbUnit.Tests.dll
Report folder:
Report types:
Filter Category:
Filter Author:
Filter Namespace:
Filter Type:
Verbose: False

ps: Filtering is a brand new feature of MbUnit that I will discuss in another thread.

posted on Thursday, July 15, 2004 10:28:00 AM (Pacific Daylight Time, UTC-07:00)  #    Comments [1]
# Wednesday, July 14, 2004

An installation tutorial "for Dummies" is available at http://www.dotnetwiki.org/Default.aspx?tabid=55

posted on Wednesday, July 14, 2004 1:09:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

With all those addins poping out on the blog, maintaining the files was becoming quite messy. In order to simplify a lot of things, I have upgraded my old www.dotnetwiki.org web site to DotNetNuke 2.1.2 with the following components:

  • Issue tracker for the Reflector Addins, please use it instead of sending the bugs to Lutz,
  • Forums, what thread can be watched by emails and news feed,
  • Download section, where the files are stored and link remain permanent

See you seen on www.dotnetwiki.org .

posted on Wednesday, July 14, 2004 12:30:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [2]
# Tuesday, July 13, 2004

After this afternoon crash of the blog, it is time to get back to some fun activities...and today code coverage is the program. I will be using NCover (gotdotnet) but other tools could apply also.

There is one thing that strikes me with code coverage: there is almost no efficient tool to visualize coverage (I'm leaving aside Team System for now). Usually the framework that compute the coverage already have a big job to do with computing it, and the visualization is somehow "left to the user". It seems to me that this part of the job is not trivial also because of the quantity of information that has to be processed: an assembly can have hundreds of types, thousands of methods. This motivates the introduction of some new...  Reflector Addins for code coverage visualization.

Coverage in a TreeMap

A natural way of visualizing coverage is to use the TreeMap that I was previously using for the Type TreeMap addin.With some minor modifications, we have the following result: the figure shows the test coverage of NCollection project (green is fullly covered, red is not covered).

NCover and Reflector

The most difficult/annoying part of this work was to create the bridge between NCover and Reflector, because of slight difference in the way name, assembly and modules are named.

posted on Tuesday, July 13, 2004 9:02:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [10]

Following the PropertyGrid and the XmlSerialization addin, this addin displays the control classes inside Reflector.

The addin is desesperately simple: if the selected class inherits from System.Windows.Forms, the addin instanciate it and adds it to the window.

posted on Tuesday, July 13, 2004 1:39:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [0]

This is a preview of a new Reflector addin to well let you search for Program Patterns in your assemblies. The addin is mainly an adaptation to .Net of the article from Santany Paul and Atul Prakash, "A Framework for Source Code Search using Program Patterns".

What are Program Patterns ?

In their article, the authors use a pattern language to specify high-level patterns for making queries on the source code. It smells like regular expression but it operates on statements and expression instead of strings. The basic pieces of the pattern languages are:

  • # describes any expression,
  • @ describes any statement,
  • more to come here...

More specific patterns, like if, while, throw,  are also defined. In fact, for each interface of the Reflector.CodeModel namespace, a corresponding pattern class is needed. Let's illustrate this with a simple example of query: Find all occurence of a if followed by a throw statement.
In the original paper notation, the pattern is defined as follows:

if (#) throw #;

Of course this will have to change a bit for C#.

C# implementation

In my implementaiton, the IPattern interface defines a Program Pattern:

public interface IPattern
{
    bool Match(Object target);
}

The interface is intentionaly simple to enable great extensibility. This interface is then specialized for IStatement, IExpression, IBlockStatement, etc.. For example, the pattern to match a throw statement will be implemented as follows:

public class ThrowExceptionStatementPattern : StatementPattern
{
    // pattern for the expression that is throwed. Pats is a helper class
    private ExpressionPattern expression = Pats.AnyExpression;
    ...

    public override bool Match(IStatement statement)
    {
        // trying to cast statement to IThrowExceptionStatement
        IThrowExceptionStatement th = statement as IThrowExceptionStatement;
        // did not cast, no match
        if (th==null)
            return false;
        // expression did not match, no match
        if (!this.Expression.Match(th.Expression))
            return false;
        // we have a match!
        return true;
    }
}

To ease up things, a helper class containing static methods (Pats) takes care of creating those objects.

Implementing the example

Implementing the example is now just a matter of putting the pieces together. We need a pattern for the if, one for the throw and a pattern that will recurse in all the statements:

// provided by Reflector
IMethodDeclaration visitedMethod = ...
// if pattern
ConditionStatementPattern ifthen = Pats.If();
// setting the Then pattern
// StatementInBlock says the pattern should be in the IBlockStatement
// Pats.Throw() returns a ThrowExceptionStatementPattern 
ifthen.Then = Pats.StatementInBlock(Pats.Throw());
// a pattern that will recurse all the statements
RecursiveStatementPattern rec = Pats.Recursive(ifthen);

// launching the seach
rec.Match(visitedMethod.Body);

Testing the example

The above pattern has been applied to the following class where 2 methods match the pattern, and 2 do not match it:

public class CodeMatchingTest
{
    public void If(bool arg)
    {
        Console.WriteLine("This method has a if");
        if (arg)
            Console.WriteLine("arg is true");
        else
            Console.WriteLine("arg is false");
    }
    public void Throw()
    {
        throw new Exception();
    }
    public void IfThrow(bool arg)
    {
        if (arg)
            throw new Exception();
    }
    public void IfThrowHiddenInsideWhileLoop(bool arg)
    {
        int i = 0;
        while(i<10)
        {
            if (i>5)
                throw new Exception();
            Console.WriteLine(i.ToString());
        }
    }
}

And the result in Reflector is displayed below. As expected, IfThrow and IfThrowHiddenInsideWhileLoop have matched the pattern.

posted on Tuesday, July 13, 2004 1:38:00 PM (Pacific Daylight Time, UTC-07:00)  #    Comments [3]