C#, C++, Windows & other ramblings

Windows 8 Pro on an early 2009 iMac 21.5 (Core 2 Duo)

noreply@blogger.com (Pete Barber) — Wed, 21 Nov 2012 08:44:00 +0000

A couple of weeks back I thought I'd have a go writing a Windows Store App. To this requires Windows 8. At the time I was running Windows 7 Home Premium on an early 2009 iMac 21.5 (Core 2 Duo). This had been installed using Boot Camp including install Boot Camp assistant and the drivers supplied by Apple.

To upgrade to Windows 8 I wanted to avoid a re-installation of all my apps. and data etc so I went with an in place upgrade. This all seemed to work properly and soon I was running Windows 8 and could access the Windows Store App templates from Visual Studio. However, soon after Windows 8 kept crashing, well freezing. It got to the point that after every reboot I'd be lucky to get 5 minutes of up time between each freeze.

Given that Apple haven't provided Windows 8 drivers yet this wasn't exactly a surprise. I decided to try and work around this by rebooting to OS X and using VMWare Fusion to access the Boot Camp partition. Whilst rebooting in OS X I managed to corrupt the Windows installation. I use a non-Apple wireless keyboard (as I need the insert, delete, home & end plus the easily accessible cursor keys for VS development) so holding down Alt to select the OS to boot into didn't work. When I realized it was going back into Windows I just turned the machine off. After a couple of times the Windows installation was toast! To get back to the point of trying Fusion I had to do a fresh Windows install. In this case installing a minimal Windows 7 installation: just enough to allow the download of Windows 8. I then installed Windows 8 using the preserve nothing option.

Having now gone through the steps I wanted to avoid I decided to give the new installation a go via direct boot, i.e. no Fusion. That was two weeks ago. Since then I've re-installed all the apps. and my personal data and (fingers crossed) haven't had a single crash. As the freezes were usually happening during some graphical operation e.g. a status bar updating I assumed the fault probably lay with the video drivers. I didn't install Boot Camp assistant and in particular the Windows 7 drivers from OS X disc. Well, I did install one. After a while I noticed I wasn't getting any sound even though all the audio drivers and hardware claimed they were happy. Eventually I installed by the Cirrus Logic driver which made the speakers work. I haven't gone anywhere near the NVIDIA drivers.

So, the whole point of this post is for those who run Windows via Boot Camp on early iMac's that if you want to run Windows 8 then perhaps a fresh install (or maybe uninstall the Boot Camp supplied drivers prior to upgrade) is probably the way to go.

Specifying the directory to create SQL CE databases when using Entity Framework

noreply@blogger.com (Pete Barber) — Fri, 03 Aug 2012 11:49:00 +0000

In the last few posts I've been describing how to create instances of SQLCE in order to perform automated Integration Testing using NUnit and accessing the dB using Entity Framework. I covered creating the dB using both Entity Framework and the SQL CE classes. In particular I wanted control over the directory the dB was created in but I didn't want to tie to a specific location rather let it use the current working directory.

Using the Entity Framework's DbContext constructor that takes the name of a connection string or database name it's suddenly very easy to end up NOT creating the dB you expected where you expected it to be. This post shows how to avoid these. Generally speaking the use of the DbContext constructor that takes a Connection String should be avoided unless the name of a connection string from the .config file is being specified.

Example 1 - Using the SqlCeEngine class

1:  const string DB_NAME = "test1.sdf";  
2:  const string DB_PATH = @".\" + DB_NAME; // Use ".\" for CWD or a specific path  
3:  const string CONNECTION_STRING = "data source=" + DB_PATH;  
4:    
5:  using (var eng = new SqlCeEngine(CONNECTION_STRING))  
6:  {  
7:    eng.CreateDatabase();  
8:  }  
9:    
10:  using (var conn = new SqlCeConnection(CONNECTION_STRING))  
11:  {  
12:    conn.Open(); // do stuff with db...  
13:  }  
14:

The important thing to note is that the constructor for SqlCeEngine that takes an argument requires a Connection String, i.e. a string containing the "data source=...". Just specifying the dB path is not sufficient. To specify a specific directory include the absolute or relative path. To specify the current working directory, e.g. bin\debug then just use ".\".

Example 2 - Using DbContext (doesn't work)

1:  using (var ctx = new DbContext("test2.sdf"))  
2:  {  
3:    ctx.Database.Create();  
4:  }

This code appears to work but doesn't create an instance of an SQL CE dB as desired. Instead it creates a localDB instance in the user's home directory. In my case: C:\Users\Pete\._test.sdf.mdf (& corresponding log file). This is not really surprising as Entity Framework had no way of knowing that a SQL CE dB should be created.

Example 3 - Using DbContext (does work)

1:  Database.DefaultConnectionFactory =  
2:    new SqlCeConnectionFactory(  
3:      "System.Data.SqlServerCe.4.0",  
4:      @".\", "");  
5:    
6:  using (var ctx = new DbContext("test2.sdf"))  
7:  {  
8:    ctx.Database.Create();  
9:    // do stuff with ctx...  
10:  }

The difference between the last and this example is changing the default type of dB that EF should create. As shown this is done by installing a different factory.

The 3rd parameter to SqlCeConnectionFactory is the directory that the dB should be created in. Just like the first example specifying ".\" means the current working directory and specifying an absolute path to a directory will lead to them being created there.

NOTE: As per the post Integration Testing with NUnit and Entity Framework be aware that creating a dB using the Entity Framework results in the additional table '_MigrationHistory' being created which EF uses to keep the model and dB synchronized.

NOTE1: Whereas SqlCeEngine is a SQL CE class from the System.Data.SqlServerCe assembly, SqlCeConnectionFactory appears to be part of the System.Data.Entity assembly which is part of the Entity Framework.

In the above example the string passed to DbContext can be a name (of a connection string from the .config file) or a connection string. In this case passing the name of the db, i.e. test2.sdf is equivalent to passing "data source=test2.sdf", well more or less. If the '.sdf' suffix is omitted with "data source" then the resultant dB is called test2 but if just test2 is passed then the resulting dB will be called test2.sdf.

Example 4 - Using DbContext and the .config file

1:  using (var ctx = new DbContext("test5"))  
2:  {  
3:    ctx.Database.Create();  
4:  }

App or Web .config

1:  <connectionStrings>  
2:    <add name="test5"  
3:      providerName="System.Data.SqlServerCe.4.0"  
4:      connectionString="Data Source=test5.sdf"/>  
5:  </connectionStrings>

This time no factory is specified but the argument to DbContext is the name of a Connection String in the .config file. As can be seen this contains similar information to that in the factory method enabling EF to create a dB of the correct type.

To use these the instances of these databases rather than calling the create method on the context just use the context directly or more likely in the case of EF a derived context which brings us to one last example.

Example 5 - Using a derived context and .config file

1:  public class TestCtx : DbContext  
2:  {      
3:  }  
4:  using (var ctx = new TestCtx())  
5:  {  
6:    ctx.Database.Create();  
7:  }

App or Web .config

1:  <connectionStrings>  
2:    <add name="TestCtx"  
3:      providerName="System.Data.SqlServerCe.4.0"  
4:      connectionString="Data Source=test6.sdf"/>  
5:  </connectionStrings>

If a derived context is created which will almost certainly be the case then if an instance of this is created and a dB created then EF will look for a Connection String in the .config file that has the same name as the context and take the information from there.

Integration Testing with NUnit and Entity Framework

noreply@blogger.com (Pete Barber) — Thu, 02 Aug 2012 14:10:00 +0000

This post gives a quick introduction into creating SQL CE dBs for performing Integration Tests using NUnit.

In the previous post Using NUnit and Entity Framework DbContext to programmatically create SQL Server CE databases and specify the databse directory a basic way was shown to how to create a new dB (using Entity Framework's DbContext) programmtically. This was used to generate a new dB for a test hosted by NUnit.

The subsequent post Generating a SQL Server CE database schema from a SQL Server database using Entity Framework showed how to generate a SQL CE dB schema from an existing SQL Server database.

This post ties theprevious ones together. As mentioned in the first post the reason for this is an attempt at what amounts to Integration Testing using NUnit. I'm currently building a Repository and Unit Of Work abstraction on top of Entity Framework which will allow the isolation of the dB code (in fact it will isolate and abstract away most forms of data storage). This means any business logic can be tested with a test-double that implements the Repository and UnitOfWork interfaces; which is straight forward Unit Testing. The Integration Testing is to verify that the Repository and Unit Of Work implementations work correctly.

The rest of the post isn't focused on these two patterns; though it may mention them. Instead it documents my further experience of using NUnit to writes tests that interact with dB via Entity Framework. The premise for this is that a dB already exists.

As such the approach to using Entity Framework is a hybrid of Database First and Code First in that the dB schema exists and needs be maintained outside of EF and also that EF should not generate model classes, i.e. allowing the use of Code First POCOs. This is possible as the POCOs can be defined, a connection made to dB and then the two are conflated via an EF DbContext. It then seems that EF creates the model on the fly (internally compiles it) and as long as the POCO types map to the dB types then it all works as if by magic!

The advantage of doing it this way is that the existing dB is SQL Express based but for the Integration Testing a new dB can be created when needed, potentially one per test. In order to keep the test dBs isolated from the real dB SQL Server Compact Edition (SQL Server CE V4) was used. Therefore the requirement was for the EF code to be able to work with SQL Express and SQL CE with the primary definition of the schema taken from SQL Express. It's not possible to use exactly the same schema as SQL CE only has a subset of the data-types provides by SQL CE. However, the process described in the post Generating a SQL Server CE database schema from a SQL Server database using Entity Framework showed how to create semantically equivalent SQL.

From this point onwards it's assumed that an SQL file to create the dB has been generated. Now create a new C# class library project and using the NUGet add Entity Framework, NUnit and SQL CE 4.0. All my work has been with EF 4.3.1. Following this drag the Model1.edmx.sqlce file from the project used to generate to new project. You may wish to rename it, e.g. to test.sqlce.

Creating the database

The post Generating a SQL Server CE database schema from a SQL Server database using Entity Framework showed how to create a new CE dB per-test using the EF DbContext to do the hard work. A different approach is now taken as the problem with creating a dB using DbContext is that in addition to creating any specified tables and indices etc. it also creates an additional table called '__MigrationHistory' which contains a description of the EF model used to create the dB. The description of the problem caused by this will be delayed until the "Why DbContext is no longer used to create the database" section. Suffice to say for the present using the new mechanism avoids the creation of this table.

The code below is the beginnings of a test class. It is assumed all the tests need a fresh copy of the dB hence the creation is performed in the Setup method. All this code does is create a SQL CE dB and then
creates the schema.

1:  [TestFixture]  
2:  public class SimpleTests  
3:  {  
4:   const string DB_NAME = "test.sdf";  
5:   const string DB_PATH = @".\" + DB_NAME;  
6:   const string CONNECTION_STRING = "data source=" + DB_PATH;  
7:   [SetUp]  
8:   public void Setup()  
9:   {  
10:    DeleteDb();  
11:    using (var eng = new SqlCeEngine(CONNECTION_STRING))  
12:     eng.CreateDatabase();  
13:    using (var conn = new SqlCeConnection(CONNECTION_STRING))  
14:    {  
15:     conn.Open();  
16:      string sql=ReadSQLFromFile(@"C:\Users\Pete\work\Jub\EFTests\Test.sqlce");  
17:      string[] sqlCmds = sql.Split(new string[] { "GO" }, int.MaxValue, StringSplitOptions.RemoveEmptyEntries);  
18:      foreach (string sqlCmd in sqlCmds)  
19:       try  
20:       {  
21:        var cmd = conn.CreateCommand();  
22:    
23:        cmd.CommandText = sqlCmd;  
24:        cmd.ExecuteNonQuery();  
25:       }  
26:       catch (Exception e)  
27:       {  
28:        Console.Error.WriteLine("{0}:{1}", e.Message, sqlCmd);  
29:        throw;  
30:       }  
31:    }  
32:   }  
33:   public void DeleteDb()  
34:   {  
35:    if (File.Exists(DB_PATH))  
36:     File.Delete(DB_PATH);  
37:   }  
38:   private string ReadSQLFromFile(string sqlFilePath)  
39:   {  
40:    using (TextReader r = new StreamReader(sqlFilePath))  
41:    {  
42:     return r.ReadToEnd();  
43:    }  
44:   }  
45:  }  
46:

The dB file (Test.sdf) will be created in the current working directory. As the test assembly is located in <project>\bin\debug which is where the NUnit test runner picks up the DLL from this directory this is where it is created. If a specific directory is required then the '.\' can be replaced with the required path.

The Setup method is marked with NUnit's SetUp attribute meaning it will be invoked on a per-test basis creating a new dB instance for each test. The DeleteDb method could be marked with [TearDown] attribute but at the moment any previous dB is deleted before creating a new one. It would be fine to do both as a belt and braces approach. The reason I didn't make it the TearDown method is so that I could inspect the dB following a test if needed.

SQL CE does not support batch execution of SQL scripts which is where it gets interesting as the SQL generated previously is in batch form. The code reads the entire file into a string and determines each individual statement by splitting string on the 'GO' command that separates each SQL command.

To help understand the SQL the following is the diagram of the dB I'm working with. All fields are strings except for the Ids which are numeric.

Each of these commands is then executed. The previously generated SQL (the SQL for the dB I'm working with is below) will not work completely out of the box. The ALTER and DROP statements at the beginning don't apply as the schema is being applied to an empty dB, these should be removed. Interestingly the schema generation step for my dB seems to miss out a 'GO' between the penultimate and ultimate statement. I had to add one by hand. Finally, the comments at the end prove a problem as there is no terminating 'GO'. Removing these fixes the problem. In the code above the exception handler re-throws the exception after writing out the details. For everything to proceed the SQL needs modifying to execute perfectly. If the re-throw is removed then the code will tolerate individual command failures which in this context really just amount to warnings.

NOTE: Text highlighted in red has been removed and text in blue added.

-- --------------------------------------------------

-- Entity Designer DDL Script for SQL Server Compact Edition

-- --------------------------------------------------

-- Date Created: 07/29/2012 12:28:35

-- Generated from EDMX file: C:\Users\Pete\work\Jub\DummyWebApplicationToGenerateSQLServerCE4Script\Model1.edmx

-- --------------------------------------------------

-- Dropping existing FOREIGN KEY constraints

-- NOTE: if the constraint does not exist, an ignorable error will be reported.

-- --------------------------------------------------

ALTER TABLE [RepComments] DROP CONSTRAINT [FK_RepComments_Reps];

-- --------------------------------------------------

-- Dropping existing tables

-- NOTE: if the table does not exist, an ignorable error will be reported.

-- --------------------------------------------------

DROP TABLE [RepComments];

DROP TABLE [Reps];

DROP TABLE [Roads];

-- --------------------------------------------------

-- Creating all tables

-- --------------------------------------------------

-- Creating table 'RepComments'

CREATE TABLE [RepComments] (

[CommentId] int IDENTITY(1,1) NOT NULL,

[RepId] int NOT NULL,

[Comment] ntext NOT NULL

);

-- Creating table 'Reps'

CREATE TABLE [Reps] (

[RepId] int IDENTITY(1,1) NOT NULL,

[RepName] nvarchar(50) NOT NULL,

[RoadName] nvarchar(256) NOT NULL,

[HouseNumberOrName] nvarchar(50) NOT NULL,

[ContactTelNumber] nvarchar(20) NOT NULL,

[Email] nvarchar(50) NULL

);

-- Creating table 'Roads'

CREATE TABLE [Roads] (

[Name] nvarchar(256) NOT NULL

);

-- --------------------------------------------------

-- Creating all PRIMARY KEY constraints

-- --------------------------------------------------

-- Creating primary key on [CommentId] in table 'RepComments'

ALTER TABLE [RepComments]

ADD CONSTRAINT [PK_RepComments]

PRIMARY KEY ([CommentId] );

-- Creating primary key on [RepId] in table 'Reps'

ALTER TABLE [Reps]

ADD CONSTRAINT [PK_Reps]

PRIMARY KEY ([RepId] );

-- Creating primary key on [Name] in table 'Roads'

ALTER TABLE [Roads]

ADD CONSTRAINT [PK_Roads]

PRIMARY KEY ([Name] );

-- --------------------------------------------------

-- Creating all FOREIGN KEY constraints

-- --------------------------------------------------

-- Creating foreign key on [RepId] in table 'RepComments'

ALTER TABLE [RepComments]

ADD CONSTRAINT [FK_RepComments_Reps]

FOREIGN KEY ([RepId])

REFERENCES [Reps]

([RepId])

ON DELETE NO ACTION ON UPDATE NO ACTION;

-- Creating non-clustered index for FOREIGN KEY 'FK_RepComments_Reps'

CREATE INDEX [IX_FK_RepComments_Reps]

ON [RepComments]

([RepId]);

-- --------------------------------------------------

-- Script has ended

-- --------------------------------------------------

Getting the SQL into a state where it will run flawlessly is a little bit of a hassle but given the number of times it will be used subsequently it's job a big job, well for a small dB anyway. To verify that your dB has been created as needed an quick and easy way to test is to comment out the call to DeleteDb() and after a test has run open to the dB using Server Explorer within VS, i.e.

Using the dB in a test

Now that a fresh dB will be created for each test it's time to look at simple test:

1:  [Test]  
2:  public void TestOne()  
3:  {  
4:   using (var conn = new SqlCeConnection(CONNECTION_STRING))  
5:    using (var ctx = new TestCtx(conn))  
6:    {  
7:     ctx.Roads.Add(new Road() { Name = "Test" });  
8:     ctx.SaveChanges();  
9:     Assert.That(1, Is.EqualTo(ctx.Roads.Count()));  
10:   }  
11:  }

Road in this case is defined as:

1:  class Road  
2:  {  
3:   [Key]  
4:   public string Name { get; set; }  
5:  }

The first thing to note is that EF is not used to form the connection to the dB, instead one is made using the SqlCe specific classes. Attempting to get EF to connect to a specific dB instance when not referring to a named connection strings in the .config file is a bit of an art (I may write another entry about this). However, EF is quite happy to work with an existing connection. This makes for a good separation of responsibilities in the code where EF manages the interactions with the dB but the control of the connection is elsewhere.

NOTE: It is likely that each test will require a connection and a context hence rather it might make more sense to move the creation of the SqlCeConnection and the context (TestCtx in this case) to a SetUp method and as these resources need disposing of adding a TearDown method to do that. TestCtx could also be modified to pass true to the DbContext constructor to give ownership of the connection to the context so that it will dispose of it then context is disposed off.

I would have preferred to avoid having to defined a specific derived context and instead use DbContext directory, e.g.

1:  [Test]  
2:  public void TesTwo()  
3:  {  
4:   using (var conn = new SqlCeConnection(CONNECTION_STRING))  
5:    using (var ctx = new DbContext(conn, false))  
6:    {  
7:     ctx.Set<Road>().Add(new Road() { Name = "Test" });  
8:     ctx.SaveChanges();  
9:     Assert.That(1, Is.EqualTo(ctx.Set<Road>().Count()));  
10:    }  
11:  }

However when SaveChanges() is called the following exception is thrown:

System.InvalidOperationException : The entity type Road is not part of the model for the current context.

This is because EF knows nothing about the Road type. When a derived context is created for the first time I think EF performs reflection on any properties that expose DbSet. These are the types that form the Model. Another option is to create the model, optionally compile it and then pass it to an instance of DbContext. This way involves a lot less code.

That's it. The final section is just footnote about the move away from using EF to create the dB.

Why DbContext is no longer used to create the database

As mentioned creating the dB using:

1:  using (var ctx = new DbContext("bar.sdf"))  
2:  {  
3:   ctx.Database.Create();  
4:   // create schema etc.  
5:  }

causes the '__MigrationHistory' table to be created. Assuming this method was used, later on when TestCtx was used top open the dB and perform an operation the following exception would be thrown:

System.InvalidOperationException : The model backing the 'DbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
This is because the context used to create the model was a raw DbContext (as per the previous post) whereas the dB was accessed via the TestCtx. If the context used to create the dB is also changed to TestCtx then this problem goes away.
However, given the original dB is not intended to be created nor be maintained (code migrations) by EF then using the non-context/EF approach to dB completely removes EF from the picture.

Generating a SQL Server CE database schema from a SQL Server database using Entity Framework

noreply@blogger.com (Pete Barber) — Wed, 27 Jun 2012 17:40:00 +0000

In a previous entry I described how to programmatically create (& destroy) a SQL CE dB for integration testing using NUnit. Since getting that working I ran into a couple of other problems which I've more or less solved so I thought I'd write those up. To begin with though this is a prequel post describing how to obtain the SQL script to create the SQL CE dB.

If you happen to be working exclusively with CE then you'll already have your schema file. In my case I'm using SQLExpress and as this is experimental work I created my dB by hand. However, using the EF it's pretty easy to obtain the schema and have the EF wizard generate the CE schema. This is important as there are differences in the dialect of SQL used by SQL Express and SQL CE and its easier to have a tool handle those, though it doesn't do all of them.

The basic flow is to generate an EF model (EDMX) file from the existing SQL Express database and then use the 'Generate database from model' functionality. It is at this point that the target SQL dB can be chosen, i.e. SQL Server, SQL Server CE or some others.

To create a model requires adding a 'New Item' of type 'ADO.Net Entity Data Model' to a VS project so first a new dummy project needs creating. This is where it gets a little complicated as not any type of project will do. I'm working with CE 4 and require a schema for that version of the dB (though creating one for 3.5 works but I like to things as close to ideal as possible). Due to this constraint it is necessary to chose a Web type project as for some reason the VS2010 integration provided by EF only supports the generation of CE 4 dBs for Web projects. If a simple C# Windows Console project is selected then you're limited to CE 3.5. Thus the simplest project type is the 'ASP.Net Empty Web Application' as shown below.

Having done this, next add a new item of type ADO.Net Entity Data Model as below. NOTE: The project will have to reference the Entity Framework assemblies. The easiest way to do this (& the one most people are probably using) is to use the NuGet package.

Then follow the wizard.

Selecting "Generate from database".

Choose your SQLExpress (or SQL Server) dB but uncheck the "Save entity connection settings in Web.Config as:" as we're converting to SQLCE so want to minimize anything related to other types of SQL Server.

Finally select the SQL elements you require. In this example only the existing tables were selected. As this is generating the EF model from an existing database no SQL file is generated just the model for which the diagram is shown, i.e.

The next phase is to generate the SQL from the model (which was generated from the hand crafted db) but to make sure the SQL that's generated is compliant with SQL CE.

To generate the schema right click and select "Generate model from database..."

This brings up the "Generate database" wizard which is very similar to the previously used "Entity Data Model" wizard used to create the model. From here choose the "New Connection" option which pops up another set of dialogs. On the first choose the type of data source as "Microsoft SQL Server Compact 4.0".

Clicking on continue then leads to the next dialog where you need to create a dB.

Ok-ing this leads back to the "Generate database wizard".

This time check the "Save entity connection settings in Web.Config" checkbox. This information will be useful later (to be covered in a different post). Clicking "Next" the SQL is generated and present in the wizard.

This can be copied & pasted directly from here or pressing "Finish" will save the SQL to the file indicated at the top of the dialog box. This file is added to the project. The following prompt will appear when "Finish" is pressed.

This doesn't really matter as this is a throw away project but having the updated schemas maybe useful so go with "Yes".

The SQL can now be used to configure an empty SQL CE 4.0 database. The easiest way is to open the SQL file and right-click selecting the "Execute SQL" menu item.

This brings up the SQL Server dialog from which if "New Database" is selected an CE 4 one can be specified.

Having specified a location and pressed "Ok" the SQL script is executed. As can be seen below this is not without errors. However, this isn't anything to worry about as the errors are to do with dropping tables and indices that currently don't exist as it's a newly created dB. Performing the same steps but missing out the creation of the dB file as it already exists sees the SQL script execute flawlessly.

The final picture shows the newly created database in VS2010's Server Explorer demonstrating that the tables were indeed created.

The basis for this post is my experimentation on using NUnit to programmatically test some dB based functionality. If a single instance of a database suffices for all your tests and you can execute the SQL by hand as above and then you can follow these steps. In may case I want to a fresh database per test so I need to automate the running of the SQL Script combined the with the creation and destruction of the underlying database. The creation and deletion aspect were covered in a previous post but the next step will have to wait until a later one.

More computing humor

noreply@blogger.com (Pete Barber) — Thu, 03 May 2012 12:04:00 +0000

A few more computer/programming related jokes. This time courtesy of the ACCU general mailing list:

I heard a good concurrency joke recently, about 10,000 threads. It was a bit contentious... (Ewan Milne)

A programmer walked into a Bar. I say a Bar, it was actually a Foo. (Frances Buontempo)

Two programmers are sitting in a bar discussing static and dynamic languages. The next day they get a visit from the RSPCA. When they ask what it's concerning, the RSPCA man says "We got a tip off that you were using ducks for typing". (Anthony Williams)

An SEO expert walks into a bar, bars, pub, public house, Irish pub, drinks, beer…. (Anders Knatten)
Q: WHY DID THE HACKER GO TO THE BEACH? A: EASY ACCESS TO SHELLS (@yeahok)

Unit Testing when the success case is compilation failure (with C++)

noreply@blogger.com (Pete Barber) — Mon, 16 Apr 2012 18:35:00 +0000

There is an issue with the use of Window’s COM types being used with STL containers in versions of Visual Studio prior to 2010. The crux of the matter is that various COM types define the address-of operator and instead of returning the real address of the object they return a logical address. If the STL container re-arranges its contents this can lead to corruption as it can unwittingly manipulate an object at the incorrect address.

The prescribed solution to this problem is to not place the COM types directly into the STL container but instead wrap them with the ATL CAdapt class. When adopting this approach there are two important aspects to consider:

Firstly, is there a way to prevent incorrect usage of the containers?
Secondly, assuming this is possible, is there a way to make sure it covers the various permutations of STL containers and COM types that are being used?

It turns out that the first issue is easily solved using template specialization. The hard part though is creating a set of unit tests that ensure specializations have been created for all permutations and that they are active. This is made even more difficult by the fact a successful use of the specialization results in compilation failure.

This too can be solved by combing various template mechanisms and techniques: SFINAE & Template Meta-programming etc. In the April issue of the ACCU Overload journal I have written article that describes this problem along with the solution. Please follow the link below (and then jump to page 24 in the PDF if it doesn't open there automatically).

http://accu.org/var/uploads/journals/overload108.pdf#page=24

The complete source code the article is also available on GitHut: https://github.com/petebarber/TemplateArticleExamples

Using NUnit and Entity Framework DbContext to programmatically create SQL Server CE databases & specify the databse directory

noreply@blogger.com (Pete Barber) — Mon, 02 Apr 2012 19:27:00 +0000

NOTE: An update to the method used here is provided in this newer post: Integration Testing with NUnit and Entity Framework.

I won't go into the why but I wanted to write what probably amounts to an integration test of an Entity Framework model. I decided to use NUnit for this. Even though it's predominately for Unit Testing there's no reason why it can't be used for other forms of testing. In fact I think the SpecFlow BDD framework eventually performs its tests using NUnit: It's not what you've got but what you do with it!

The application I'm writing uses SQL Express but for my tests I wanted to create & destroy a database frequently and locally so I opted to use SQL Server Compact Edition. This is pretty easy to do with EF's DbContext: just create an instance of it, pass in either the name of the database or a Connection String, e.g.

[Test]
public void TestWithConnectionString()
{
var db = new DbContext("Name=Foo");

db.Database.Create();
}

which references the following Connection String in the .config file

<connectionStrings>
<add name="Foo"
providerName="System.Data.SqlServerCe.4.0"
connectionString="Data Source=foo.sdf"/>
</connectionStrings>

As I'm going to be potentially creating many of these I wanted precise control over their name and location. This meant I didn't really want to use a Connection String as this is more or less hard-coded in the .config file.

Instead I opted to create it programmatically. By default DbContext expects to be using SQL Server in particular an instance of SQLExpress named .\SQLExpress. This is easily changed by replacing the DefaultConnectionFactory with the factory class for SQL Server CE: SqlCeConnectionFactory.

The first parameter to the constructor is the type of the factory class which allows instances of different versions to be created. This is simply the providerName as per the Connection String. The second parameter is the directory to create any new databases in. The third parameter (unused in the example below) are options to append to the generated Connection String. The code below will result in the creation of C:\UsersPete\TestDBs\bar.sdf assuming the directory exists and the user has appropriate permissions and bar.sdf does not already exist.

[Test]
public void TestWithFactory()
{
Database.DefaultConnectionFactory =
new SqlCeConnectionFactory(
"System.Data.SqlServerCe.4.0",
@"C:\Users\Pete\TestDBs\", "");

var db = new DbContext("bar.sdf");

db.Database.Create();
}

That's mainly it: A simple way to programmatically create databases. This code should really be moved to the SetUp method and a corresponding TearDown method added to delete the database; oh, and some tests!

I haven't got that far yet and the actual reason for writing the entry was for a short while despite specifying the directory for the databases, i.e. C:\Users\Pete\TestDBs they were being created in the current working directory. This was because rather than just specifying the name of the database as the argument to DbContext I was passing the string "DataSource=bar.sdf" of which the name part appears to be an absolute path and thus override that specified in the SqlCeConnectionFactory. As only a file name is present it uses the current working directory for the path element. If you've got the same issue (whether integration testing or not) this might save you a little time.

A C#/.NET Attributes Based Command Line Argument Parser

noreply@blogger.com (Pete Barber) — Wed, 18 Jan 2012 19:00:00 +0000

I've been meaning to add a blog entry for this for a while. It's just a link to my latest Code Project article that went live last week. It's a long piece describing a small library for handling the parsing of command line arguments in C# programs, either Console or GUI (there's a WPF example).

This is the first project I created using Test Driven Development so as well as the technical details of the library there's also a description of how I found TDD.

You can find it here: http://www.codeproject.com/KB/cs/NAttrArgs.aspx

Open Source C# Network File System (NFS) Server (for Windows)

noreply@blogger.com (Pete Barber) — Wed, 04 Jan 2012 13:57:00 +0000

Happy New Year!

Not a proper post but just a quick link to my latest Code Project article. A few years ago I wrote an NFS Server (in C#). I had reason to revisit this lately so I thought I might as well write it up as a Code Project article and Open Source it. You can grab it from GitHub.

Links:

Article: http://www.codeproject.com/KB/IP/NFSServer.aspx
Source: https://github.com/petebarber/NFS

Obtaining the size of a C++ array using templates and other techniques (from C++11) - Part 2

noreply@blogger.com (Pete Barber) — Tue, 06 Dec 2011 13:07:00 +0000

Welcome back! In Part 1 we saw a nifty technique to obtain the size of an array via function template argument deduction. However, this ended with the problem of how to use this value at compile time, e.g. as the size of another array. This proves hard in C++98 but C++11 changes things.

The simplest way to enable compile time use is to make use of the new constexpr keyword. This tells the compiler that the function can be completely evaluated (to a constant value) at compile. As such C++11 allows this function to be called at compile time though instead the evaluated constant value is used. Adding this to the definition of GetNumberOfElements as below

template<typename T, size_t sizeOfArray>
constexpr size_t GetNmberOfElements(T (&)[sizeOfArray])
{
return sizeOfArray;
}

now allows the following to compile

char a[100];
char b[GetNumberOfElements(a)];

Is this the best that we can do? Using raw array types isn't that good. Even though the size of the array is known and can now be discovered at compile time using it in std::for_each is somewhat burdensome as the length must be obtained in order to obtain the end iterator, i.e.

std::for_each(&a[0], &a[GetNumberOfElements(a)], SomeFunctor());

Due to the raw array not being an object it doesn't have an end method which means the code must rely on the programmer specifying the correct index for the end of an array or using the technique above.

This can be remedied by moving from raw array types to std::array (first made available in TR1), e.g.

std::array<char, 100> a;
std::for_each(std::begin(a), std::end(a), SomeFunctor());

(Note the use of the C+11 non-member versions begin and end functions)

The downside of using std::array is that even though it can be initialized when defined, e.g.

std::array<int, 4> a = { 0, 1, 2, 3 };

It effectively requires the length of the array specifying twice. Firstly as the template parameter and then again implicitly by the number of elements in the initializer list.

Given the new initializer list feature of C++11 it could be expected that this would allow initialization without the length parameter. However it seems this is not supported "out of the box" though there are some interesting techniques to allow this.

All is not lost though. Taking a step back and returning to the raw array the size issue can be circumvented by use of C++11's range-for statement.

char a[100];
SomeFunctor sf;
for (auto x : a)
sf(x);

To backtrack once again, the use of the non-member versions of begin and end can also be used on raw arrays so the example above can also be written as:

char a[100];
std::for_each(std::begin(a), std::end(a), SomeFunctor());

Which if the purpose of the loop is to invoke a functor then std::for_each is more succinct than range-for as it doesn't require an explicit instance of the functor.

I suspect the same technique for finding the length of a naked array along with constexpr is used by the non-member version of end to obtain the length. In fact one version of end is probably a function template overloaded to accept a raw array as its container parameter, e.g.

template<typename T, size_t>
constexpr T* example_begin(T (&array)[])
{
return &array[0];
}

template<typename T, size_t sizeOfArray>
constexpr T* example_end(T (&array)[sizeOfArray])
{
return &array[sizeOfArray];
}

char a[100];
std::for_each(example_begin(a), example_end(a), SomeFunctor());

However, any looping mechanism that requires both the start and end to be specified rather than just the container does allow for an error to occur by having begin and end of different containers specified whereas range-for eliminates this possibility!

In summary, it's possible to find the size of a raw array using function template deduction and using C++11 features that value can be used at compile time. However, if the reason that the size needs obtaining is to obtain the end iterator then C++11 makes this redundant through the use of range-for and the non-member versions of begin and more accurately end.

Obtaining the size of a C++ array using templates and other techniques (from C++11) - Part 1

noreply@blogger.com (Pete Barber) — Fri, 18 Nov 2011 13:52:00 +0000

Recently I was helping somebody debug an issue around the use of swprintf_s. The issue turned out to an Obi-Wan (off by one) error. I don't tend use the likes of printf() very much instead preferring to use a std::stringstream if I need to format into a string.

I'd assumed that the Microsoft's secure versions of these methods, i.e. those with _s suffix took a buffer size so when looking at the help for swprintf_s I was momentarily taken aback by the lack of a buffer parameter. However I then noticed that swprintf_s is not just a regular function but is in fact a function template:

template <size t size>
int swprintf_s(
wchar_t (&buffer)[size],
const wchar_t *format [, argument] ...); // C++ only

One of the most useful properties of a function template is its ability to deduce its argument types. In this case the argument is not a type parameter but a fundamental type (though using the size_t typedef) that specifies the size of the target string buffer (in characters not bytes). When used as:

wchar_t buf[10];
swprintf_s(buf, "%d", 10);

It deduces that the size of the buffer (buf) is 10. This works because the template parameter is used to specify the size of the expected wchar_t array that swprintf_f expects. It could have been specified as in swprintf_s<10>(buf, "%d, 10) but this is where the beauty lies in that the compiler is able to deduce it. This is what function templates do and how they're often used so there's nothing novel here accept the application of finding an array size. This is a really neat trick and I don't know why I've missed it for so long!

An important point here is that the signature is a reference to an array (note the & before buffer) as opposed to the array syntax of just wchar_t (buffer)[size]. If this were used the function template would be unable to deduce the parameter (size). This is because the syntax:

template<size_t size> foo(wchar_t (buffer)[size])

decays to become:

template<size_t size> foo(wchar_t* buffer);

When compiled, i.e. foo() can accept a pointer to a wchar_t array of any size. In fact a pointer to wchar_t* is fine. There is nothing special about this and it's just the standard decay that C (and C++) has always supported.

Anyway, after that slight diversion into decay let's return to deducing the size of an array. So why is this is this useful? In order to iterate over each of any arrays elements, e.g.

int a[] = { 0, 1, 2, 3, 4 };for (int i = 0; i < sizeof(a)/sizeof(int); ++i)
SomeFn(i);

or slightly better:

int a[] = { 0, 1, 2, 3, 4 };
std::for_each(&a[0], &a[sizeof(a) / sizeof(int)], &SomeFn);

The number of elements is required in order to terminate the iteration.

The concept can be generalized to obtain the size of any type of array, i.e.

template<typename T, size_t sizeOfArray> int GetNmberOfElements(T (&)[sizeOfArray])
{
return sizeOfArray;
}

Which can be used to rewrite the previous examples as:

int a[] = { 0, 1, 2, 3, 4 };
std::for_each(&a[0], &a[GetNumberOfElements(a)], &SomeFn);

Returning to the discussions about decay it should be noted that this mechanism only works for actual arrays. The signature used to prevent decay, i.e. using the '&' means that a pointer cannot be passed, e.g.

char *pa = new char[100];
GetNumberOfElements<char, 100>(pa);

Won't compile with VC++ 2010 giving:

Error 3 error C2664: 'GetNumberOfElements' : cannot convert parameter 1 from 'char *' to 'char (&)[100]'

This makes perfect sense as it's explicitly requires an array. Even if for some reason it could accept the pointer then it wouldn't be able to deduce the size because this information isn't syntactically available (though will be most likely embedded within memory block that pa points too; quite possibly a few bytes further back so that when delete [] is invoked the C++ runtime will know how much memory to free). Looking at the MSDN help for swprintf_s() it is clear why additional definitions (the non-template overloads) are provided as these deal with passing pointers.

Now that this cool feature can be used to easily obtain array sizes the next thing you tend to want to do is then define other arrays using this information, i.e.

char a[100];
char b[GetNumberOfElements(a)];

However this won't compile as despite the fact that GetNumberOfElements() performs (well the compiler does) the size deduction at compile time the result is only available at runtime. To define an array the size must be known at compile time.

There is a clever hack to make this available at compile time but it requires the use a macro which is unpleasant. However, at this point it's C++11 to the rescue but that'll have to wait until part 2 which is available here.

Unit Testing C# Custom Attributes with NUnit Part 4

noreply@blogger.com (Pete Barber) — Wed, 17 Aug 2011 18:10:00 +0000

In Unit Testing C# Custom Attributes with NUnit Part 3 towards the end I showed the following code

Assert.That(MethodBase.GetCurrentMethod(), 
            Has.Attribute<FunkyAttribute>().Property("SettingOne").TypeOf<int>());

to test the type of a property on an attribute. As it turns out this does not actually do that. Instead it tests the type of the value returned from the property. What's happening is that the object returned from Property() isn't some of meta-object representing a property but is the actual value of the property.

In the case above it amounts to the same thing. As the property type is an int even if it has not been set the value will be 0 of which type is int. However, if it's a reference type (quite likely a string) or a nullable type the value can be null. E.g.

Assert.That(MethodBase.GetCurrentMethod(), 
     Has.Attribute<FunkyAttribute>().Property("FunkyName").TypeOf<string>());

Which causes the following when run:


AttrTestV3.FunkyTester.TestThatTheTypeOfFunkyNameWhenNotSetIs_string:
  Expected: attribute AttrTestDefs.FunkyAttribute property FunkyName <System.String>
  But was:  <AttrTestDefs.FunkyAttribute>

It seems that when there is no value Property() which tests for the presence of a the specified property name and implicitly returns the value of the property (if found) has nothing to return so for some reason the attribute type obtained from the call Has.Attribute() is returned.

Currently, there is no way with NUnit to handle this case. I started a thread on the NUnit discussion group which discusses this issue and it seems like the authors of NUnit have some plans.

As an interim solution if the property is optional for a custom attribute then in the fixture make sure a value is assigned. In the case above:

[Test]
[Funky(FunkyName = "dummy")]
public void TestThatTheTypeOfFunkyNameWhenNotSetIs2_string()
{
    Assert.That(MethodBase.GetCurrentMethod(),
         Has.Attribute<FunkyAttribute>().Property("FunkyName").TypeOf<string>());
}

I think that's the end again:-) Here are the links to the previous parts: One, two & three.

Spectating with Twitter: Twittating or Spectwiting

noreply@blogger.com (Pete Barber) — Sun, 14 Aug 2011 15:44:00 +0000

Today I went to watch (spectate) a small part of the London-Surrey Cycle Classic. Being a 160KM cycle race it wasn't possible to see a lot of it. Even though it featured one of Britain's most prominent and successful cyclists Mark Cavendish the BBC or I suppose any other TV companies chose not to broadcast it live, in fact there didn't seem to be any conventional mainstream live media coverage. Bummer!

However, Twitter to the rescue. There seemed to be several authoritative sources (@cyclingweekly, @roadcyclinguk, @antmccrossan and @CycleSurrey); presumably travelling with the race or being fed data from someone who was that were Tweeting throughout the race. Given the dearth of information, following these people or the searches #CycleClassic and/or #testevent was the the only way to find out anything.

I suspect it's how most people were informed of the result; Mark Cavendish won! I was wondering if this was the first time for a major sporting event (unless you're from the BBC) that the majority of spectators 'watched' via Twitter, i.e. Twittating or should that be Spectwiting! Now this doesn't differ too much from receiving text message updates to a sporting event or just checking the score except that this was largely unofficial and the only available channel. In addition the community aspect of Twitter generated an almost a stadium like atmosphere albeit virtual.

The lack of live coverage also meant that in addition to no information there were no pictures either. However a lot of the tweets had accompanying pictures and some videos. Whilst not live TV it was something. Even more interesting given the nature of the event: a cycle road race, it meant that the stream of Tweets was actually charting the progress of the race.

Thinking about this the natural extension is the possibility of broadcasting an event purely by the crowd on Twitter. If there are enough people to cover a course and whatever lag Twitter; and mobile Internet access has doesn't interfere too much then as the race passes the current status along with images could be Tweeted.

This stream could be consumed in real time by a special Twitter client that pulls it together chronologically and importantly will display pictures. These wouldn't be continuous motion (well they could be if the intervals between each Tweeter were short enought) but would give a visual sense of the event. This is essentially newspaper reporting but in near real time as opposed to live TV which is real time.

One other thought on the basis that the highlights won't be available for a week is that it should be possible to write a program to consume the previously mentioned Twitter searches and pull these together along with the attached pictures and videos to create some sort of watch-able programme.

A couple of computing jokes

noreply@blogger.com (Pete Barber) — Thu, 04 Aug 2011 20:08:00 +0000

The problem with a UDP joke is that you have no idea if people get it. (from @fearthecowboy)

A SQL query walks into a bar, goes up to a couple of tables and says, "Can I join you?".

Unit Testing C# Custom Attributes with NUnit Part 3

noreply@blogger.com (Pete Barber) — Tue, 26 Jul 2011 21:16:00 +0000

During Unit Testing C# Custom Attributes with NUnit Part 2 where the Assertions were converted from the Classic to the Constraint model it was simply a process of replacing

Assert.<SomeAssertion>(<object>)

with

Assert.That(<object>, Is.<SomeAssertion>)

The key thing being the 'Is' object that houses all the original assertions used. Whilst doing this I came across the 'Has' object. This doesn't appear in the documentation until about halfway when collections are covered. Not mentioned at all in the documentation is the method Has.Attribute<AttributeType> which tests whether an attribute (custom or otherwise) is present on the object being tested. For the current method this is simply:

Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>());

Even better, having obtained the Attribute (if not present the assertion will fail) it too can be tested. The important aspect here is that it contains a specific property which can easily be tested in the same statement by appending '.Property(<PropertyName>)' in a Fluent style to give:

Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("FunkyName"));

The next is to test whether this property contains the correct value. This can be obtained in a similar way by further appending '.EqualTo(<SomeValue>)' to give:

Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("FunkyName").EqualTo("RipSnorter"));

In a single statement tests for the presence of the Custom Attribute, a property of it and finally that property's value have been conducted. This is considerably shorter than both the original and second examples which required the reflection code to obtain the Custom Attribute followed by 3 separate assertions.

This does not meet the original testing requirements which were:

A Custom Attribute of the correct type existed on the test method.
That the property to be tested of the Custom Attribute had the expected name.
That the property to be tested of the Custom Attribute had the correct type.
That the value of property to be tested of the Custom Attribute could be set.
That the value of property to be tested of the Custom Attribute could be obtained.
That the property to be tested of the Custom Attribute had the expected value.

Remaining are setting, getting (obtain) and type checking.

It turns out that that the tests for being able to set and get the property are not needed as if a property is created on a Custom Attribute then a getter and setter must be supplied. The property can be private but if this is the case then it cannot be set as part of the Attribute syntax. If the former condition is not met or an attempt is made to set a private property then a compilation error will occur.

Whilst successfully testing the property's value would suggest a type match this it not strictly the case as if the expected value can be converted to the type of the property then the test will be successful, e.g.

Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("SettingOne").EqualTo(77.0));

which causes the double to be converted to an int. It wouldn't be possible to actually set 'SettingOne' to a double value when using the attribute as this will fail to compile, e.g.

[Funky(SettingOne = 77.9)]

As this is testing an implementation of a Custom Attribute rather than its application then it is necessary to check that the implementation hasn't been accidentally changed to allow this in which case the previous erroneous test would pass. This means testing the type.

Unfortunately this is where the Fluent interface of NUnit's Constraint model falls downs a little as it's not possible to perform multiple tests on the same initial subject which in this case is the MethodBase returned from the static MethodBase.GetCurrentMethod() call. Therefore an additional assertion is required:

Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("SettingOne").TypeOf<int>());

This means the original example can be reduced to the following:

[Test]
//[Funky(FunkyName = "RipSnorter")]
public void TestThatNameIsRipSnorter()
{
 Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("FunkyName").EqualTo("RipSnorter"));
 Assert.That(MethodBase.GetCurrentMethod(), Has.Attribute<FunkyAttribute>().Property("FunkyName").TypeOf<string>());
}

[Test]
[Funky(SettingOne = 77)]
public void TestThatSettingOneIs77()
{
 // Two asserts
 Assert.That(MethodBase.GetCurrentMethod(), 
             Has.Attribute<FunkyAttribute>().Property("SettingOne").EqualTo(77));
 Assert.That(MethodBase.GetCurrentMethod(), 
             Has.Attribute<FunkyAttribute>().Property("SettingOne").TypeOf<int>());

 // Use of '.And'.  Note the trailing '.'
 Assert.That(MethodBase.GetCurrentMethod(), 
             Has.Attribute<FunkyAttribute>().Property("SettingOne").TypeOf<int>().
             And.Attribute<FunkyAttribute>().Property("SettingOne").EqualTo(77));

// Use of overloaded '&'
 Assert.That(MethodBase.GetCurrentMethod(), 
             Has.Attribute<FunkyAttribute>().Property("SettingOne").TypeOf<int>()
           & Has.Attribute<FunkyAttribute>().Property("SettingOne").EqualTo(77));
}

with the Custom Attribute definition remaining as

public class FunkyAttribute : Attribute
{
 public int SettingOne { get; set; }
 public string FunkyName { get; set; }
}

In the TestSettingOneIs77 method the need for two separate assertions has been slightly improved upon.  This is by using the 'And' method which is of the Fluent style.  The final assertion is exactly the same as the previous but just demonstrates the overloaded '&' syntax instead.

I don't think either of these styles is particularly better than the two line equivalent as they both require two calls to obtain the Custom Attribute; one for each test.  However, using NUnit's Constraint model coupled with Fluent interface reduces the required code dramatically so is worthwhile.  Additionally I'm not sure if the Classic model actually allows Attributes to be obtained.

A test per-property on a Custom Attribute is probably also desirable but there's nothing stopping you combining all the individual property tests into a single assertion by the use of  '.And.HasAttribute().Property().EqualTo()'.  One of these would be required  for each of the remaining properties along with a similar one for the type check.  A test per-property is more readable.

I think I'm done for a while on this subject now!

Unit Testing C# Custom Attributes with NUnit Part 2

noreply@blogger.com (Pete Barber) — Tue, 26 Jul 2011 19:29:00 +0000

I thought that my last post about Unit Test C# Custom Attributes with NUnit was going to be the only one. However, after reading more of the NUnit documentation I found that despite the QuickStart guide using the Classic model the preferred model for working with NUnit is that of Constraints. As such I thought I ought to change over to this which is what the updated code below shows.

[Test]
[Funky(FunkyName = "RipSnorter")]
public void TestThatNameIsRipSnorter()
{
 TestAttrProperty<FunkyAttribute, string>(MethodBase.GetCurrentMethod(), "FunkyName", "RipSnorter");
}

[Test]
[Funky(SettingOne = 77)]
public void TestThatSettingOneIs77()
{
 TestAttrProperty<FunkyAttribute, int>(MethodBase.GetCurrentMethod(), "SettingOne", 77);
}

// Helpers
private void TestAttrProperty<TAttr, TProp>(MethodBase method, string argName, TProp expectedValue)
{
 object[] customAttributes = method.GetCustomAttributes(typeof(TAttr), false);

 Assert.AreEqual(1, customAttributes.Count());

 TAttr attr = (TAttr)customAttributes[0];

 PropertyInfo propertyInfo = attr.GetType().GetProperty(argName);

 Assert.That(propertyInfo, Is.Not.Null);
 Assert.That(propertyInfo.PropertyType, Is.EqualTo(typeof(TProp)));
 Assert.That(propertyInfo.CanRead, Is.True);
 Assert.That(propertyInfo.CanWrite, Is.True);
 Assert.That(propertyInfo.GetValue(attr, null), Is.EqualTo(expectedValue));
}

The major change is rather that than calling Assert.<Assertion> the Constraint model starts with specifying the object to be tested followed by the test. Additionally, the Constraint model encourages a Fluent style interface, e.g.

Assert.IsNotNull(propertyInfo);

becomes

Assert.That(propertyInfo, Is.Not.Null);

I'm not going to explain the new model here (the above link has the details) but rather this is to just point out this style which can be contrasted to the sample in the previous post.

In addition I remembered that a far easier way to obtain the current method metadata, i.e. MethodBase was to simply to use reflection by calling MethodBase.GetCurrentMethod() from System.Reflection.

You might also have noticed that in this updated example the FunkyAttribute property Name has become FunkyName.

public class FunkyAttribute : Attribute
{
 public int SettingOne { get; set; }
 public string FunkyName { get; set; }
}

This was to differentiate from the Name property of the PropertyInfo class.

However, this isn't the main reason for part 2. However, this post seems long enough already so the good bit will come in part 3 which I'll write immediately so not too much waiting around. A part 4 also emerged!

Unit Testing C# Custom Attributes with NUnit

noreply@blogger.com (Pete Barber) — Wed, 20 Jul 2011 20:23:00 +0000

I've been experimenting with TDD and as usual I've seemed to pick a non-standard problem to start with. In this case I was creating a new C# Custom Attribute class, e.g.

public class FunkyAttribute : Attribute
{
 public int SettingOne { get; set; }
 public string Name { get; set; }
}

which would be used such as

[Funky(Name="SomeThingFunkierThanJust_f")]
public static int f() { return 7; }

Testing this is a little strange as rather than having a standard test method which invokes a method and asserts the result, e.g.

[Test]

public void TestThat_f_Returns7()
{
 Assert.AreEqual(7, SomeClass.f());
}

There is no method to call because an Attribute is applied to an element of the program such as the definition of f() above. In the end I settled on the following

public class FunkyTester
{
 [Test]
 [Funky(Name="RipSnorter")]
 public void TestThatNameIsRipSnorter()
 {
  TestAttrProperty<FunkyAttribute, string>(new StackFrame().GetMethod(), "Name", "RipSnorter");
 }

 [Test]
 [Funky(SettingOne=77)]
 public  void TestThatSettingOneIs77()
 {
  TestAttrProperty<FunkyAttribute, int>(new StackFrame().GetMethod(), "SettingOne", 77);
 }

 // Helpers
 private void TestAttrProperty<TAttr, TProp>(MethodBase method, string argName, TProp expectedValue)
 {
  object[] customAttributes = method.GetCustomAttributes(typeof(TAttr), false);

  Assert.AreEqual(1, customAttributes.Count());

  TAttr attr = (TAttr)customAttributes[0];

  PropertyInfo propertyInfo = attr.GetType().GetProperty(argName);

  Assert.IsNotNull(propertyInfo);
  Assert.AreEqual(typeof (TProp), propertyInfo.PropertyType);
  Assert.IsTrue(propertyInfo.CanRead);
  Assert.IsTrue(propertyInfo.CanWrite);
  Assert.AreEqual(expectedValue, (TProp)propertyInfo.GetValue(attr, null));
 }
}

This test class contains 2 test methods which are identified by the NUnit [Test] attribute. In addition there is the use of the FunkyAttribute to be tested, i.e. [Funky]. The Custom Attribute is fairly simple with a default (parameterless) constructor and just two; differently typed properties both with a getter and a setter. For each of these I wanted to check :

A Custom Attribute of the correct type existed on the test method.
That the property to be tested of the Custom Attribute had the expected name.
That the property to be tested of the Custom Attribute had the correct type.
That the value of property to be tested of the Custom Attribute could be set.
That the value of property to be tested of the Custom Attribute could be obtained.
That the property to be tested of the Custom Attribute had the expected value.

As I wanted to perform these tests for each property of the Custom Attribute a helper method was called for which in this case is TestAttrProperty. This method is generic so can be used for any property of a Custom Attribute that has a public getter and setter. It just takes a reference to an instance of the a method (which will always be a Test method) that the Custom Attribute is set on along with parameters for the property's name and its expected value. The latter is a generic typed parameter (TProp) along with the type of the actual Custom Attribute (TAttr).

TestAttrProperty() then obtains all the Custom Attributes instances matching the type of TAttr. There can only be zero or one; the success case being one! By limiting the search to just the Custom Attribute type being tested this means that the NUnit TestAttribute instance is not included which means no filtering of the results is required prior the tests. Following that reflection is used to obtain the PropertyInfo of the property under test. This is then used for execution the remaining of the tests.

The MethodInfo for the test method is easily obtained from the current stack frame from the System.Diagnostics namespace

Hopefully, this little snippet shows a simple generic way to test Custom Attributes with NUnit.

A next step would be to add the ability to test that the Custom Attribute can be successful applied to data members.

Wait, there's more! Following this parts two, three and four were written.

A Simple WPF ComobBox based Brush Selector Control

noreply@blogger.com (Pete Barber) — Mon, 18 Jul 2011 17:30:00 +0000

Following the last Code Project article I popped my stack and finished the original article that spawned it. It's up on Code Project now and you can find it here or in long hand: from http://www.codeproject.com/KB/WPF/BrushSelectorArticle.aspx

As the title suggests this one shows how to implement a simple control that allows a SolidColorBrush to be selected from a panel. In fact it demonstrates how to do with using a Style and a UserControl and compares both approaches.

Exploring the use of Dependency Properties in WPF User Controls

noreply@blogger.com (Pete Barber) — Tue, 12 Jul 2011 12:06:00 +0000

I recently wrote my first WPF User Control. This was mainly to customize a ComboBox as opposed to implement a completely new control. As such, I needed to access some of the Dependency Properties (DPs) on the ComboBox. Whilst it's possible to dip into the Content property of a UserControl this is somewhat unpleasant as it violates encapsulation. The result was that I spent a bit of time experimenting with different ways to access these DPs whilst retaining the encapsulation of the embedded ComboBox. This is all written up as a Code Project article.

http://www.codeproject.com/KB/WPF/DPsInUserControl.aspx

Am I living in Dilbert?

noreply@blogger.com (Pete Barber) — Tue, 21 Jun 2011 21:20:00 +0000

I was in a lift at work yesterday. Unusually I was in the Sales building. I entered the lift on the ground floor and pressed the button for the second floor. The lift stopped at the first floor and a salesman entered. He proceeded to ask me "are you going down?". I replied "no" which I expected to be the end of the conversation, well at least concerning my very immediate travel plans. However, this was not to be and you can probably guess what came next: "are you going up?". A little to close to Dilbert for comfort:-)

Getting WPF SizeChanged Events at start-up when using MVVM and DataContext

noreply@blogger.com (Pete Barber) — Sun, 12 Jun 2011 16:27:00 +0000

Like lots of people working with WPF I've been writing my own MVVM framework. I started using this in an application I was writing. One of the things it needed to do was obtain the dimensions of a Canvas object. As such a subscription to the SizeChanged event was used. The connection was formed using DataBinding to my implementation of an event-to-command mapper.

The code below are the classes from the MVVM framework plus a sample application that demonstrates the problem. This is just a button within a Canvas that when pressed pops up a dialog displaying the Canvas's dimensions.

<Window x:Class="SizeChangedEventTest2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525"
  xmlns:mvvm="clr-namespace:PABLib.MVVM;assembly=PABLib.MVVM"
  xmlns:local="clr-namespace:SizeChangedEventTest2">
 <Canvas mvvm:EventCommand.Name="SizeChanged" 
   mvvm:EventCommand.Command="{Binding SizeChanged}">
  <Button Content="Hello" Command="{Binding PressMe}"/>
 </Canvas>
</Window>

The code below shows my basic implementation of the command-to-event pattern. I would have left it out but seeing but how it's used is crucial to the explanation of the problem and the solution. Please note that EventCommand is actually in the PABLib.MVVM namespace as referred to in the XAML above but I've left it out of the C# to save space.

public class EventCommand
{
 public static DependencyProperty CommandProperty = DependencyProperty.RegisterAttached("Command",
    typeof(ICommand),
    typeof(EventCommand));

 public static void SetCommand(DependencyObject target, ICommand value)
 {
  target.SetValue(EventCommand.CommandProperty, value);
 }

 public static ICommand GetCommand(DependencyObject target)
 {
  return (ICommand)target.GetValue(CommandProperty);
 }

 public static DependencyProperty EventNameProperty = DependencyProperty.RegisterAttached("Name",
    typeof(string),
    typeof(EventCommand),
    new FrameworkPropertyMetadata(NameChanged));

 public static void SetName(DependencyObject target, string value)
 {
  target.SetValue(EventCommand.EventNameProperty, value);
 }

 public static string GetName(DependencyObject target)
 {
  return (string)target.GetValue(EventNameProperty);
 }

 private static void NameChanged(DependencyObject target, DependencyPropertyChangedEventArgs e)
 {
  UIElement element = target as UIElement;

  if (element != null)
  {
   // If we're putting in a new command and there wasn't one already hook the event
   if ((e.NewValue != null) && (e.OldValue == null))
   {
    EventInfo eventInfo = element.GetType().GetEvent((string)e.NewValue);

    Delegate d = Delegate.CreateDelegate(eventInfo.EventHandlerType, typeof(EventCommand).GetMethod("Handler", BindingFlags.NonPublic | BindingFlags.Static));

    eventInfo.AddEventHandler(element, d);
   }
   // If we're clearing the command and it wasn't already null unhook the event
   else if ((e.NewValue == null) && (e.OldValue != null))
   {
    EventInfo eventInfo = element.GetType().GetEvent((string)e.OldValue);

    Delegate d = Delegate.CreateDelegate(eventInfo.EventHandlerType, typeof(EventCommand).GetMethod("Handler"));

    eventInfo.RemoveEventHandler(element, d);
   }
  }
 }

 static void Handler(object sender, EventArgs e)
 {
  UIElement element = (UIElement)sender;
  ICommand command = (ICommand)element.GetValue(EventCommand.CommandProperty);

  var src = Tuple.Create(sender, e);

  if (command != null && command.CanExecute(src) == true)
   command.Execute(src);
 }
}

The bindings used in the XAML refer to properties in Window's ViewModel. This is defined as follows:

class MainWindowViewModel
{
 public ICommand PressMe { get; private set; }
 public ICommand SizeChanged { get; private set; }

 private int m_width = 0;
 private int m_height = 0;

 public MainWindowViewModel()
 {
  SizeChanged = new PABLib.MVVM.RelayCommand<object>((x) =>
  {
   SizeChangedEventArgs args = (SizeChangedEventArgs)((Tuple<object, EventArgs>)x).Item2;
   m_width = (int)args.NewSize.Width;
   m_height = (int)args.NewSize.Height;
  });

  PressMe = new PABLib.MVVM.RelayCommand<object>((x) =>
  {
   MessageBox.Show(string.Format("Width:{0}, Height:{1}", m_width, m_height));
  });
 }
}

For the sake of completeness here is the implementation of RelayCommand. This is pretty much the basic version as originally created by Josh Smith.

public class RelayCommand<T> : ICommand
{
 Action<T> _Execute { get; set; }
 Predicate<T> _CanExecute { get; set; }

 public RelayCommand(Action<T> execute, Predicate<T> canExecute = null)
 {
  _Execute = execute;
  _CanExecute = canExecute;
 }

 public bool CanExecute(object parameter)
 {
  if (_CanExecute == null)
   return true;
  else
   return _CanExecute((T)parameter);
 }

 public void Execute(object parameter)
 {
  if (_Execute != null)
   _Execute((T)parameter);
 }

 public event EventHandler CanExecuteChanged
 {
  add { CommandManager.RequerySuggested += value; }
  remove { CommandManager.RequerySuggested -= value; }
 }
}

However, rather than just obtaining the dimensions when changed these were also required when the Canvas was first shown. The problem was that when using my MVVM framework it was only capturing events if the window was resized but not the initial sizing event. For the sample app. this meant pressing the button the first time yielded results of 0 for both width and height. I switched back to a conventional code-behind page approach as a sanity check. This worked!

At this point I started debugging the code more and discovered that the initial SizeChanged event was being fired and handled by the EventCommand code. However, when it came to invoke the ICommand associated with the EventCommand this was null (in the Handler method of EventCommand). The strange thing here was that that the event name had been successfully passed to EventCommand but the command hadn't. Both of these are stored as Attached Properties (as is normal for event-to-command implementations).

The difference between the event name and the command is that event name was a hard-coded string in the XAML whereas the command was being obtained using data binding to the main window's ViewModel. Therefore the culprit appeared to be that the binding hadn't executed. There was no problem with the validity of the binding as all the SizeChanged events bar the initial were being received and in debug mode VS was not reporting an issues with the binding.

The only thing I could think of is that the initial event was being fired before the binding had been processed. This was confirmed by extending the Attached Property definition for the CommandProperty to include an CommandChanged callback e,.g.

public static DependencyProperty CommandProperty = DependencyProperty.RegisterAttached("Command",
   typeof(ICommand),
   typeof(EventCommand),
   new FrameworkPropertyMetadata(CommandChanged));

private static void CommandChanged(DependencyObject target, DependencyPropertyChangedEventArgs e)
{
}

A break point set on CommandChanged showed this wasn't invoked until after the event had fired confirming that the binding hadn't occurred.

The way the ViewModel was set as the Data Context for the main Window was by removing the StartupUri element from the Application element in App.xaml.cs, e.g.

<Application x:Class="SizeChangedEventTest2.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
         
    </Application.Resources>
</Application>

and modifying App.xaml.cs to be:

public partial class App : Application
{
 protected override void OnStartup(StartupEventArgs e)
 {
  base.OnStartup(e);

  MainWindowViewModel vm = new MainWindowViewModel();
  MainWindow win = new MainWindow();
  win.DataContext = vm;

  this.MainWindow = win;
  this.MainWindow.Show();
 }
}

After some searching I noticed other projects setting the DataContext of the main window (to the ViewModel) in different ways. This got me to thinking that perhaps the DataContext was being established too late.

To address this App.xaml and App.xaml.cs were put back to their initial states and instead the ViewModel created and attached in the constructor for MainWindow, e.g.

public partial class MainWindow : Window
{
 public MainWindow()
 {
  this.DataContext = new MainWindowViewModel();

  InitializeComponent();
 }
}

This fixed the problem! As an experiment InitializeComponent() was moved to top of the constructor. It stopped working. I didn't particularly like creating the ViewModel here so instead this code was removed and instead it was created in XAML as follows:

<Window x:Class="SizeChangedEventTest2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525"
  xmlns:mvvm="clr-namespace:PABLib.MVVM;assembly=PABLib.MVVM"
  xmlns:local="clr-namespace:SizeChangedEventTest2">
 <Window.DataContext>
  <local:MainWindowViewModel/>
 </Window.DataContext>
 <Canvas mvvm:EventCommand.Name="SizeChanged" mvvm:EventCommand.Command="{Binding SizeChanged}">
  <Button Content="Hello" Command="{Binding PressMe}"/>
 </Canvas>
</Window>

This too worked. This is where I'm currently at. From this I conclude that it is critically important to make sure that a View's DataContext is properly created and attached before the underlying Window is displayed otherwise initial events will be missed.

Some thoughts on the iPad 2 actual feel

noreply@blogger.com (Pete Barber) — Sun, 29 May 2011 08:40:00 +0000

After using the demo iPad 2s in various shops I decided to take plunge and get one. I'd been reading so much stuff on the Internet especially RSS feeds on the iPhone that I wanted a larger screen and to be able to read longer articles in comfort.

This isn't a review but something I've noticed during my first week of ownership. Along with the iPad I also bought one of the new covers. When playing in the shops I'd only used the bare the metal version which was very pleasant to hold and manipulate.

However, I am now rather averse to using the iPad without the cover. I tend to hold the iPad in book mode and having the cover folded underneath the feel is of a natural fabric rather than metal. This has almost turned the iPad from a machine into something else: almost a book or another kind of natural object. It's an interesting sensory experience.

I occasionally remove the cover, usually to quickly reattach it which shows the other neat aspect which is how easily it self-aligns. The only thing it's missing is when folded underneath is the ability to 'stick' to the underneath so it does feel like a paperback folded back on itself with only a single page visible fighting to flatten itself.

First ever CodeProject article

noreply@blogger.com (Pete Barber) — Mon, 23 May 2011 17:49:00 +0000

I've been playing around with the WPF TreeView control trying to get it to draw a connected line org. chart style view of a tree. I was going to write it up here but it got a bit long and formatting for the blog is a little tricky so I turned it into a Code Project article, my first one. You can find it here.

Fluent Functors

noreply@blogger.com (Pete Barber) — Tue, 17 May 2011 18:07:00 +0000

I've been learning about BOOST Spirit; a C++ expression based compiler generator. One of the examples is for a Roman Numeral parser. This contained the following interesting code for pre-loading a symbol table.

struct ones_ : qi::symbols<char, unsigned>
{
    ones_()
    {
        add
            ("I"    , 1)
            ("II"   , 2)
            ("III"  , 3)
            ("IV"   , 4)
            ("V"    , 5)
            ("VI"   , 6)
            ("VII"  , 7)
            ("VIII" , 8)
            ("IX"   , 9)
        ;
    }

} ones;

So,

struct ones_ is a new class definition.
ones_() is the constructor
The call to add("I", 1) is a call to the member function add associating the string "I" with the value 1 by adding them to the symbol table.

There's nothing particularly strange there. However, the continuation, i.e. add()()()()()... looked a little odd and puzzled me for a minute or so. Then I realized add() must be returning *this and the other ()s were invoking the parenthesis operator, i.e. in this case ones_& operator()(const char*, const int);

Following this little revelation to confirm the theory I constructed the following program which sums the numbers 1-6 printing 21.

#include <iostream>

class Func
{
private:
    int m_sum;

public:
    Func(const int n) : m_sum(n) { /* Empty */ }

    const int Sum() const { return m_sum; }

    Func& operator()(const int n)
    {
 m_sum += n;

 return *this;
    }

    static Func add(int n) { return Func(n); }
};

int main()
{
    std::cout << Func::add(1)(2)(3)(4)(5)(6).Sum() << std::endl;
}

All that's needed is a seed function, in this case add() which returns *this followed by operator()(). It would work fine without the named seed function using just operator()() but then it would loose a little meaning.

This isn't really that helpful and in most circumstances probably constitutes obfuscated code. However it's certainly cute and where overloading is done fully and with meaning of which Spirit is a case in point then it becomes an effective and usable syntax.

As Fluent Programming seems to be on rise this another demonstration of it within C++, just like iostreams. The added Syntactical Sugar provided by C++'s Functor mechanism makes for Fluent Functors.

Evolution of C# enumerators

noreply@blogger.com (Pete Barber) — Wed, 28 Feb 2007 21:03:00 +0000

Introduction

I needed a very simple tree data structure the other day. Unfortunately C#/.NET doesn’t provide one so I implemented a simple one. The need was to create a hierarchy of folders from a flat data structure where each node contained a unique id and its parent id. The list wasn’t particularly ordered, i.e. not by depth or breadth however parent nodes always preceded child nodes so that when a node was added to the tree the parent was guaranteed to already be there. This wasn’t the important part of the exercise. The main thing I wanted to accomplish was to perform a depth first search displaying the node’s contents indented to reflect the depth that it occurred in the tree.

As this was written in C# and .NET collections are expected to support the IEnumerable interface I didn’t just want to implement a basic tree walker but do it in such a way that it conforms to the .NET paradigm. As it’s a while since I’ve implemented a tree and this is the first time I’ve used C# 2.0 enumerators I ended up going through 3 iterations of enumerator until I had what I thought was proper .NET style enumerator. This article describes this evolution. Please note that thread safety is not considered and little attention is paid to error handling or invalid conditions.

The following code shows the minimal implementation of the tree bar any enumeration code.

class Node
{
  public static Node MakeRoot() 
  {
    return new Node(0); 
  }
  private Node(int id) { id_ = id; }
  public bool Add(int id, int parentId)
  {
    if (parentId == id_)
    {
      children_.Add(new Node(id));
      return true;
    }
    else
    {
      foreach (Node child in children_)
        if (child.Add(id, parentId) == true)
          return true;
      return false;
    }
  }

  public int Id { get { return id_; } }
  private int id_ = -1;
  ArrayList children_ = new ArrayList();
}

The main program just loads a simple tree.

Node root = Node.MakeRoot();

root.Add(1, 0);
root.Add(2, 0);
root.Add(3, 0);
root.Add(11, 1);
root.Add(12, 1);
root.Add(13, 1);
root.Add(121, 12);
root.Add(122, 12);
root.Add(1211, 121);
root.Add(12111, 1211);

C Approach

Performing a depth first search is not difficult. The easiest way to implement this is to use recursion. The following is a quick implementation that proved the tree was functioning correctly.

Note that this is a member of the Node class.

public void Walk(int level)
{
  for (int i = 0; i < level; ++i)
    Console.Write("\t");

  Console.WriteLine(id_);

  foreach (Node node in children_)
    node.Walk(level + 1);
}

This implementation is how a tree would have been walked in the era of C programming. In the OO and .NET world it has a number of problems:

Breaks encapsulation as the application code, i.e. the display code is mixed with that of the data structure. Using straight C this code could be fixed by having the method take a function pointer as an argument which would be invoked for each node to display the node. In C++ this could be improved by using a functor or by implementing the whole thing as an STL compatible iterator.
The method runs until completion, i.e. it is not possible to obtain an item from the tree and perform some action on it then retrieve the next or abandon the walk altogether. However, the method could be extended to provide a mechanism to terminate early depending on the return value of the invoked method.
.NET 2.0 collections are expected to implement the IEnumerable interface which means they must provide a IEnumertor GetEnumerator(). This allows the collection to be used by any .NET entity that recognizes the standard enumeration interfaces in particular the foreach keyword which is recognized as the best mechanism for enumerating a collection.

C# 1.0 Approach

These issues can be addressed by implementing the tree walker as an enumerator. The main difficulty in doing this is that an enumerator is an iterative operation which means a separate call is made to advance the iterations whereas the tree walker is called once and only returns when the traversal is complete.

An enumerator for data structures that are suited to recursive traversal can be implemented using various techniques. Firstly on the initial call the enumerator could walk the tree recursively and build up a linear data structure that is ideally suited to iteration, i.e. create a list of depth first traversal whose members reference the actual nodes of the tree then iterate over members of the list.

The method I choose was to mimic recursion by maintaining context in the enumerator that upon the following call would take the enumerator back to where it left off. The enumerator is implemented in a separate class which can hold the state and as per the iterator pattern allow multiple instances to co-exist. The following code shows the implementation but note that even though not explicitly shown this is a nested class so has access to Node’s private members and is not visible to the caller which works only against the IEnumerator interface. It is this interface that requires the implementation of MoveNext(), Current & Reset().

class WalkNode : IEnumerator
{
  public WalkNode(Node root)
  {
    root_ = root;
  }
  bool IEnumerator.MoveNext()
  {
    if (current_ == null)
    {
      current_ = root_;            
      activeIts_.Push(root_.children_.GetEnumerator());
      return true;
    }
    else
    {
      while (activeIts_.Count > 0)
      {
        IEnumerator it = (IEnumerator)activeIts_.Pop();
        if (it.MoveNext() == true)
        {
          current_ = (Node)it.Current;
          activeIts_.Push(it);
          activeIts_.Push(current_.children_.GetEnumerator());
          return true;
        }
      }

      return false;
    }
  }
  object IEnumerator.Current
  {
    get 
    { 
      // Need to handle invalid current_
      return new NodeAndLevel(current_, activeIts_.Count - 1); 
    }
  }
  void IEnumerator.Reset() { current_ = null; activeIts_.Clear(); }
  Node root_;
  Node current_;
  Stack activeIts_ = new Stack();
}

The interesting stuff happens in MoveNext(). This is called to advance the enumerator and must be called to set the enumerator to the first item before actually using its value, i.e. calling the Current property.

On the first call the current node is set to the root node. This means that if the Current property is called then the root node will be returned. Secondly it sets the enumerator up for the subsequent call by obtaining an enumerator to the root node’s children and pushing it onto a stack stored in the enumerator. It is this stack that effectively mimics the recursion as it persists the enumerator for the current node and those in the branch above across each call and so maintains a reference to the next node to visit and which one to return to when there are no more children.

On the next (non-root node) and all subsequent calls a test is made to see if the stack contains any items. If it doesn’t then this means there are no more nodes to visit and the tree has been fully traversed. When called the second time the stack will contain the enumerator for the root node’s children. Due to the nature of the Node class a node will always be able to provide a enumerator even if doesn’t have any children but the first call to MoveNext() on it will return false indicating the end of the children, i.e. none. If the root has no children then this will be case as the enumerator (for its children) obtained from the stack will return false, the stack count will be zero so the loop will terminate and the main MoveNext() will return false indicating an end of the traversal. This will also be case when all the children of the root have been traversed.

The other case is that the root does have children in which case the internal call to MoveNext(), i.e. using the enumerator from the stack will return true in which case the member variable current_ used to implement the Current property will be set to the child node obtained from the Current property of the internal enumerator. As this is a depth first search the next node to be traversed should be the first child of this node so the current enumerator is pushed onto the stack along with the newly obtained internal enumerator for the current node’s children so on the next call its children will be enumerated. True is then returned.

In the case of the bottom of a branch being reached the internal call to MoveNext() from the just popped enumerator will return false. As the stack still has the parent enumerators on it the loop will not terminate unlike the case of a root node without children or having traversed its last. This then causes the current node’s parent’s enumerator to become the current enumerator allowing the next child along to be traversed if there is one. This continues until the stack has been popped so that current internal enumerator is that of the root node. If this contains more children the each of these nodes is traversed deeply until no more children are found causing the loop to terminate as the stack is empty and finally returning false indicating the end of the traversal.

The downside of the mimicking approach is the number of live internal enumerators that are kept alive on the stack whilst traversing deeper children. If the deepest point of the tree was 100 nodes deep then this would require 100 active internal enumerators to be on the stack. The deepest enumerator, i.e. number 100 would be for the leaf node and will yield no children.

Rather than returning the reference to a node an instance of a wrapper type is returned which allows the additional level information to be supplied. The definition of this is shown below.

class NodeAndLevel
{
  public NodeAndLevel(Node node, int level)
  {
    node_ = node;
    level_ = level;
  }

  public Node Contents { get { return node_; } }
  public int Level { get { return level_; } }

  readonly Node node_;
  readonly int level_;
}

The other modification is that Node implements the IEnumerable interface which means it must implement the GetEnumerator() method which it does. This creates an instance of the WalkNode enumerator that we have just discussed as can be seen below.

IEnumerator IEnumerable.GetEnumerator()
{
  return new WalkNode(this);
}

C# 2.0 Approach

Version 2.0 of C# added language support to make the implementation of enumerators simpler. This allows the implementation of this particular enumerator to be reduced and simplified dramatically.

class Node : IEnumerable
{
  IEnumerator IEnumerable.GetEnumerator()
  {
    return GetEnumeratorWithLevel(0);
  }
  private IEnumerator GetEnumeratorWithLevel(int level)
  {
    yield return new NodeAndLevel(this, level);
    foreach (Node node in children_)
    {
      using (IEnumerator it = node.GetEnumeratorWithLevel(level + 1))
      {
        while (it.MoveNext())
          yield return it.Current;
      }
    }
  }
  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    return this.GetEnumeratorWithLevel(0);
  }

… the rest is the same as Node at the beginning

The entire enumerator code has now been reduced to the implementation of GetEnumerator(), well almost. The helper GetEnumeratorWithLevel() is also required so an additional argument can be passed. As GetEnumerator() is implementing the interface IEnumerable<> as inherited by Node its signature cannot vary hence why it calls the helper method. As IEnumerable<> derives from the C# 1.0 interface IEnumerable as used in the previous example the weakly typed IEnumerable.GetEnumerator() must also be implemented but as can be seen this is done by calling the strongly typed version.

As generics is available the tree code has switched to using generics. This is a good thing as the caller of the enumerator is dealing with strongly typed objects that don’t require a runtime cast any more.

The enumerator class hasn’t really gone away rather the compiler has implemented it for us as a nested class just as we had to do by hand in the previous version. Again, just like the C# 1.0 implementation which used a stack to maintain the recursive state the generated code also maintains state. The key to allowing the compiler to do this is the yield return statements. This informs the compiler where the enumerator should return and that the subsequent call to MoveNext() should begin immediately after it.

In this example, the enumerator is initially called with the root node. This then yields (returns) immediately, creating a new instance of NodeLevel which will be accessible via the generated Current property.

The next call causes the enumerator to create an internal enumerator (as before in the C# 1.0 implementation) of the current node’s children, i.e. from the children_ list. This will then call MoveNext() on this internal enumerator. If the root node has no children then it will terminate and false will be returned indicating that the traversal is complete. If there are children then the yield will cause a return true and the current node will become that child. As the enumerator was created by calling GetEnumeratorWithLevel() this is effectively a recursive call but with the yield causing the return with the generated code maintaining the state including storing the references to all the internal enumerators.

Even though the generated code is hard to read and full of gotos using Reflector allows the generated code to be seen. As this implements IEnumerator<> and the derived IEnumerator Current is implemented for both and Reset for the latter. In addition, as IEnumerator<> is also derived from IDisposable Dispose is also created. This is why the apparent recursive call to GetEnumeratorWithLevel() wraps the resulting call with a using statement so that Dispose() is called.

The generated code still has to do everything the hand-coded version did including keeping open any active enumerators. As it’s generated it might be faster too but I haven’t tested this. However, it has freed us from having to write & maintain this code.