Iron Python and Boo

This is another of those parallel  developments that seem to be occouring so much lately.

Boo is  a Python-like language for the .NET Framework.

IronPython is an implementation of  Python on the .NET CLR

Boo is a great dynamic language for experimenting with .NET classes interactively, especially using the booish shell. The big adavantage of boo over c# is the lack of a compile step. This allows for editing of a running application. Boo does not yet support Generics (but this is being worked upon). Boo workings with .Net 1.1. .Net 2 and Mono.

IronPython is the first dynamic language added to the CLR family by microsoft. It is intended to demonstate that the CLR can support dynamic languages. IronPython requires .NET 2.0.

Visual Studio Template : Beyond the basics

The Microsoft documentation in msdn is both complete and lacking.

There is enough detail available to resolve most problems. However the examples are so poor that it can be hard to find out about why you would use them.

For example:

$year$ = this is expanded into the year. This is very useful for compyright headers.

They are also incomplete.

Templates in VS 2005 allow developers to easily replace or add to the items that are available when you select new item.

Templates are zip files containing:

  • .vstemplate
  • one or more custom files.

By customising these you can save a lot of cut-and-paste time and effort.

This page of Template parameters is not complete.

$safeitemrootname$ = This appears to be the name that the user enters into the dialog.

If you combine this with multi-item templates as defined here. This allows you to use the supplied name as a root of a class. For example you could have a template that takes a name such as Entity.cs that creates the following files:

  • EntityModel.cs
  • IEntityModel.cs
  • IEntityView.cs
  • IEntityController.cs
  • EntityController.cs

$fileinputname$ = This also work in the template

$XmlConvert_itemname$ = what does this do? I think this is a wizard populated item.

It appears that the WizardExtension appears to work in item templates too despite the documentation.

I will investigate this and will post about it.

Reimplementation Technique

Now that the IT industry is relatively mature there are very few new products.

In my experience a majority of projects consist of a reimplementation of an existing product making a major change.

These can include:

  • Changing the supported operating system.
  • Changing the backend database (ISAM to SQL)
  • Change of programming language
  • Design of the system (Client Server to Distributed

Alongside this the new version of the product must have exactly the same behaviour as the old system.

The old system is likely to be undocumented (or if documented the documentation will be out of date). It is highly likely that people who wrote it are no longer with the company (or have been prompoted to management).

The Reimplementation Technique consists of using the old system to create the unit test suite for the new system. This provides the means of ensuring that the new system functions in exactly the same way as the old system.

The end result is a set of unit tests that provide a good basis for future development. These tests form good documentation for what the code actually does.

Any of the xUnit test suites could be used. I use dunit here since I am familiar with it (and it is less painful to get into html).

The test suite on the new system should take no more than ten mins to run otherwise you will find that it is not used. the test suite may take longer to run against the old system as that is onlu used occasionaly to validate that the tests work on the old system.

In the example that follows I assume that we are only trying to replace the design plus the database. Similar techniques (using say code generation) would work across languages.

A few notes on using DUnit:

A test suite in DUnit looks like the following:

TMyTest = class(TTestCase)


procedure setup; override;

procedure teardown; override;


procedure Test_A;

procedure Test_B;



Dunit treats each published method as a seperate test. Setup is called before each test. Teardown is called afterwards.

The literature surrounding xUnit suggests that you should ensure that any state changes (i.e. database entries) are removed in the teardown. I find that clearing up in the setup is neater. It makes these tests easier to check manually. Also these “side effects” are great for manual user interface tests.

UI testing is difficult in xUnit. However if you can get the system in exactly the state you need (i.e. one item suffering the problem you wish to debug your life becomes much easier).

Here is a simple example.

The application being ported has a telephone list for staff. An update file is read in. It is a CSV file consisting of dept, name and number. The file should replace the contents of the database table with the new list.

The first thing to write is a generator class that will parametrically create our test data.

The tests themselves call helper methods.

Actions do real world things:

  • Create the input file
  • Read the input file

Enquiries count real world things

Count telephone entries

Count errors

Count people with name like ()

Typically these classes are contructed by a factory that returns the appropriate class depending upon a compiler directive.

A simple test could look like:

procedure TMyTest.TestDownload;


    CheckEquals(0, CountAll(), ‘Step 1’);


    CheckEquals(0, CountAll(), ‘Step 2’);



    CheckEquals(3, CountAll(), ‘Step 3’);

    CheckEquals(0, Errors(), ‘Step 4’); 



The general principle is to write the tests around business operations, not around the actual implementation.

This makes the tests far more resistant to changes in implementation.

 By keeping the actual tests abstract portability becomes much easier.

In one implementation a count could open a file and count the lines, in another a SQL statement does the job.

Jumping languages would use similar techniques. The tests themselves would need to be ported, but since most morden languages are so similar this should not be too much of a job. 

Generics Best Practice

This is the Microsoft listed best practice for generics.

I agree with the following post. Here Richard Birkby recommends subclassing generics before using them.

His argument is that this make it easier to extend (which is a good idea) but I would also recommend subclassing to reduce the repetitive nature of the code:

For example:

public class foo


public List<int> Bar


get {return _Bar;}


private List<int> _Bar;



Would be more cleanly written as:

public class IntList : List<int> {}

public class foo


public IntList Bar


get {return _Bar;}


private IntList _Bar;






Late Binding in C#

The following is an example of late binding: 

            Type objClassType;
            object objApp_Late;
            objClassType = Type.GetTypeFromProgID(“VisualStudio.DTE.8.0”);
            objApp_Late = Activator.CreateInstance(objClassType);

Exploring Visual Studio 2005

Visual Studio is a combine harvester of an IDE. It performs so mant functions that it is easy to get lost. 

I started sting to write an extension to VS.NET to allow me to use the command-line from within VS. I was trying to use the VSIP to add a managed window.  Partway through the listed steps it asked me to look at the View | Other Windows menu. I could not find the window that I had defined but  I did  find  the follwing:

  • Call Browser
  • Command Window
  • Object Test Bench 

 The call browser could be worth future investigation.

Object Test Bench allows objects to be created from the IDE.  This could be great for ad-hoc testing. (Although I typically used the TestDriven.NET which allows the test this method or test with debugger).

The Command Window looks much more useful. It contains a wonderful set of commands and is user-extensible. I can see this becoming really useful.

 Here is the list of available commands.

Technology Convergence

It is a good sign when different teams are attempting to solve the same problem.

The Castle Project has its new Generator contrib project. This is an easy to use extensible code template system written in BOO with style templates. BOO is a hybrid of Python and C# with some ideas from the Ruby world.

Microsoft has the Guidance Toolkit. This allows the Visual Studio IDE to expanded with macros and recepies.

Both of these approaches are attempts to implement Software Factories, allowing developers to raise the abstraction and reuse. This can only be a good thing. Hopefully one or both will survive.