There are many IoC containers out there in the .Net-o-sphere that are quite excellent.  Personally, I use Ninject because I love its simple syntax and its powerful contextual binding.  When I first came across Ninject some time ago (shortly after 1.0 was released) I read everything I could about it and IoC in general and then said to myself “IoC … whatever! I don’t need that crap! … way too complex”.  A startling lack of vision on my part.  Then I started getting deep into my program’s re-design from C to C#.  We have a Settings object that contains the settings the user has entered from the command-line and/or a parameter file.  Lots of objects need the Settings but sometimes these objects are fairly deep in the object graph and to get the settings I used the Singleton instance of it.  As you develop in a more object-oriented way many other circumstances like this turn up.

As I started unit testing I discovered that Ninject was born and raised for just this sort of activity: injecting objects deep into the object graph when you want them and it gets rid of the ugly Singleton instances that are such a pain when you are unit testing.  It was like I was born-again.  Praise the Ninject!  I used Ninject to create everything … and I mean everything!  I was passing parameters to the kernel to help resolve bindings, using providers where I thought I needed more complicated logic, you name it.  If I could have used Ninject to inject my lunch into my bag every day I would have.

Then it came time to performance test my application.  When I ran the performance tests they were incredibly slow … like I could have done the calculations without the computer slower.  I did some research on the net and found that there was a performance bug in Ninject 1.0 that was resolved in 1.5 and 2.0 but when I tried replacing 1.0 with 1.5 or 2.0 the performance was barely affected and still very slow.

I was perplexed so of course I went to the Ninject user group and posted a question.  The answers sort of slapped me in the face a bit.  As one of my friends at work says: I was trying to be holier than the pope!  Basically IoC containers are intended to be used to resolve long-lived instances.  This is, in fact, why some containers set the default lifetime of objects to singleton rather than transient.  To resolve large numbers of transient objects you should use the factory pattern, make the IoC Container resolve the factory as a singleton and inject any dependencies that the transient objects need into the factory.  I don’t have many types of transient objects that need to be created, only a few classes, so I created factories for them and my performance problems melted like an arctic ice pack.

So how could I have avoided this problem?  I should have been more diligent about asking questions on best practices when I first started using Ninject (or really any other piece of technology).  Most worthwhile open source projects have newsgroups or forums that are active and have some informative users who are willing to lend a hand.  In my own defense though, while doing research on IoC (and I read quite a few articles on this) never once did I come across best practices for using the tools, it was mostly the nuts and bolts of how to use a tool that documentation focuses on.  This particular problem never seemed to be discussed, though if I’m wrong maybe someone will point me to where it is discussed.  That’s the main reason I wrote this article though, to help anyone else who may have been in the same situation as me.

IoC FTW!

Bind<IEngineSession>()
	.To<DeriveEngineSession>()
	.OnlyIf(context => context.Kernel.Get<Settings>().Session == SessionType.Derive);

Bind<IEngineSession>()
	.To<DonorEngineSession>()
	.OnlyIf(context => context.Kernel.Get<Settings>().Session == SessionType.Donor);

Bind<IEngineSession>()
	.To<EditEngineSession>()
	.OnlyIf(context => context.Kernel.Get<Settings>().Session == SessionType.Edit);

Note that inside of the conditional binding I resolve an instance of the Settings object and use it.  Well, when I tried to do this with Ninject 2 I ran into some big problems because the IContext is not part of the conditional binding syntax now, it is replaced by IRequest which does not have access to the Kernel.  I was quite perplexed and put off for a while until I saw that Ninject 2 was officially released.  I thought perhaps the bug was resolved so I eagerly downloaded Ninject to try it out, only to be disappointed.  There was no IKernel as part of IRequest and the ParentContext field of IRequest was null on the initial bind so I couldn’t use that to get an IKernel object to resolve my objects.

Perplexed, I posted a question to the Ninject newsgroup asking if this was a bug.  One of the things I love about Ninject is that either Nate or Ian get back to you with lightning speed and efficiency and always have an answer at the ready.  As Ian pointed out, the binding itself has a property called Kernel that I can use, rather than getting it from the binding, like so:

Bind<IEngineSession>()
	.To<DeriveEngineSession>()
	.When(request => Kernel.Get<Settings>().Session == SessionType.Derive);

Bind<IEngineSession>()
	.To<DonorEngineSession>()
	.When(request => Kernel.Get<Settings>().Session == SessionType.Donor);

Bind<IEngineSession>()
	.To<EditEngineSession>()
	.When(request => Kernel.Get<Settings>().Session == SessionType.Edit);

I am pleased as can be now since this problem was the only thing preventing me from making the switch in all of my projects!  Thanks to Nate Kohari, Ian Davis, et al. for pouring so much love into this framework and making it a shining example.  I even gave my team a tour of the repository because, unlike some open source projects, it is very well laid out and easy to use … I maybe have even stolen some ideas (like embedding NAnt directly into the working folder and providing a script to build the project on demand) into my own projects!

• Have a meaningful version number.  For example major.minor.build.revision where revision is the revision of your version control repository.
• Build a clean copy of the source code each time (delete + svn checkout as opposed to svn update)
• Perform unit and/or integration tests to determine the quality of the build
• Gather the various deployable pieces of your application into an archive (or set of archives) that the anyone can retrieve with little trouble

While it is not necessary, some other nice things you can do as part of a continuous integration process are

• Perform static analysis of your code and produce reports on this for every build
• Perform code coverage analysis of your code and produce reports on every build
• Run integration tests using tools like Cucumber, SpecFlow or Fitnesse.
• Link build numbers back to your activity management tool (Bugzilla, Trac, Jira, TFS Work Items)
• Track who breaks builds, etc.

Real Life Continuous Integration

On my team we have been doing full-fledged continuous integration on all projects for over a year now.  We use a combination of tools to support the trinity of activities involved in configuration management.

• Subversion – Version Control tool
• Atlassian Jira – Activity Management tool
• Hudson – Continuous Integration tool

I have tried a few different continuous integration tools (VisualBuildPro, IBM Rational BuildForge and JetBrains’ TeamCity) and found Hudson to be the best among them.  There is a plethora of plug-ins available, an active user and developer support group and its open source!  Does a tool get any better?  TeamCity comes a close second but its lack of support for trend charts and plugins was a real downer.  It does have pre-flight builds but this feature wasn’t enough to win me over.  IBM Rational Build Forge was ridiculously over priced for the functionality, required a lot of manual configuration and had a confusing set of terminology (as is common with IBM Rational products).  Avoid it at all costs.  All that being said, in the end we chose Hudson and every build in Hudson has some key ingredients:

• We monitor the Subversion repositories for change every 5 minutes.
• When a change is detected Hudson deletes the old working copy and gets a fresh copy from Subversion (no svn update!!)
• The actual build is done with an NAnt script
  • You could use MSBuild, Rake or PSake instead.
  • The NAnt script builds the solution with MSBuild, runs any unit tests, calls FxCop to produce a report for some static analysis and then packages the results of the build.  For some projects we use ILMerge to reduce the number of assemblies we need to deploy as I am a heavy user of open source tools.
  • Hudson creates environment variables BUILD_NUMBER and SVN_REVISION that we use in our build script to generate the version numbers.  These get put into the AssemblyInfo.cs files and cause the Version property of the assembly to reflect the 
• NUnit plugin to read the NUnit results report and produce a trend chart on
• Violations plugin to read the FxCop results and produce a trend chart on possible code violations
• Warnings plugin to parse the MSBuild log file and produce a trend chart on compiler violations
• Task Scanner plugin parses the class files (*.cs) looking for those //TODO and // HACK (or whatever else you tell it) comments and then makes a nice report on them
• The Jira plugin is probably the nicest feature.  It parses the commit comments from Subversion for each build for tags in Jira format (i.e. PROJECT-19) and if it finds one it puts a comment in the relevant Jira issue with a link back to the Hudson build.  This is an awesome way for our users to be notified when an issue that they created has been worked on!
• A zip archive is produced with all of the materials for using the product (the executable, configuration files, etc.)

When used in conjunction with “Commit early, commit often” Hudson becomes the heartbeat of our team.  Anytime someone performs a commit we get a pile of useful trend charts and reports indicating the health of the project.  With the Jira plugin we get connection to the activity management tool so users know what build their issue has been worked on and Hudson keeps track of the source code changes for every build … in other words complete traceability!  If a user encounters a problem we can tell immediately what the version is that they’re using and whether they are up to date or not.  We can tell what has changed since the last build to determine if merely upgrading will resolve their problem.  We can point a user to a Hudson build and they can get everything they need from a single page since everything is archived in one place.

One important thing that I have found out is that it is important to have a way to build your project exactly like Hudson would, but do it locally.  This was the main reason I chose NAnt as the build script.  In my source control repository there is a .build file containing the NAnt script, a copy of the NAnt executable and

Good for you smarty-pants … but how long does it take to get all that setup if I know nothing about continuous integration?

To get my setup running it took me a solid week (spread out over time).  I started off very small, with no plug-ins and Hudson simply building the solution file.  I would add a plugin, get it working and then expand.  I think this is a good way for a newbie to start because even if you are only building the project it can catch a lot of errors.  one of the most common mistakes I find on my team is when someone adds a file to the solution file in Visual Studio but forgets to add the file to Subversion.  When they commit the change set MSBuild barfs when it cannot find the file that is not in Subversion.  This is an easy and effective way of ensuring that the source control tree is always in a buildable state.  I love this because one of my pet peeves is checking out a project only to discover it doesn’t actually build.  It’s little mistakes like these that upset the rhythm of a team and affect productivity.

In terms of tools for newcomers I would highly recommended Hudson because it is such a simple point-and-click Web 2.0 interface and has great help built right in where you need it.  Hudson is ridiculously easy to install and use, even installing it as a Windows service is built right into the package now, and installing plug-ins, etc. is downright simple.

If you’re still unconvinced you will see some payback from continuous integration (despite the evidence to the contrary) then look at the relatively minimal investment of a few days to a week as something that you can bring to every project in the future.

The Future

I would like to expand our setup to include code coverage metrics and possibly use a tool like StyleCop to measure how well the source code is formatted.  I have in the past attempted to integrate trend charts for a Fitnesse wiki but gave up because the restriction of having a wiki server up and running to perform the tests was tedious and error-prone.  We’re moving our specification tests to SpecFlow anyway and this should be considerably easier to use since its just NUnit under the hood.

Tale of woe

There is a tale of woe that is a background to this story.  The version control environment I use is a combination of Subversion on the server with Bazaar locally.  This is sort of an advanced setup but I prefer it because it lets other members of my team who are more comfortable with Subversion to stick with it but lets me use the advanced features of a a Distributed Version Control (DVCS) tool like Bazaar. 

Now one day recently I was working away on a project that had to be done quickly.  I had been working on this project for about 2 days solid, so there was a lost of changes.   I realized at one point that I had modified a file I shouldn’t have and I went to revert this file using Bazaar.  I used TortoiseBzr, right-clicked the file in Windows Explorer, selected only the single file and pressed OK.  I bet you can’t guess what happened next!  For reasons a Bazaar neophyte like myself were unaware of, the entire repository reverted.  Two days of work … gone!  … or so I thought.  After a full-on panic I finally got my head about me and I filed a bug report and got a really fast and informative reply, was able to recover my lost data and move on.  Major kudos to the Bazaar development team here, they were helpful and knowledgeable.  However, this caused me nearly 4 hours of panic-ridden stress … so how could I have avoided this faithful reader?

Commit Early, Commit Often

This mantra is repeated all over the internety-thing here, here and here.  The biggest mistake that programmers make when working with a version control system is waiting long periods of time before checking in their code.  This was the problem that caused me all that stress and it was completely avoidable.  Had I committed at least a few times a day I would have lost at most a few hours work rather than two days worth.  The next obvious question you’re going to ask me is : “What is the smallest chunk to commit”?

What do I commit?

When developers ask me this question I usually tell them something like this: If it relates to a single activity (bug, feature, task), it compiles and it passes unit tests then commit it.  It takes some experience and experimenting to come up with your own formula but I personally find if I make a few classes with their accompanying tests then that’s a unit small enough for me to check in.  This could take 20 minutes or it could take 2 hours but I try to commit at least two to three times per day at a minimum.  I really like the first answer in this stack overflow question where he states that he usually commits a “complete thought”.  It’s fairly abstract again, there is no concrete rule after all, but another possible guidance.

Benefits

There are a lot of benefits to committing code in small rather than large chunks.  Most of these become apparent when you work with another developer on the same branch.  It is much easier to resolve merge conflicts with another developer in the same branch there the merge conflict is related to just a few files rather than dozens of files.  Additionally, committing in small chunks means that if there are conflicts then you are making the scope of the problem that you have to resolve much smaller.  If you commit 2 dozen files after 4 days there could be several small conflicts that need to be resolved and worked out, all intermingling with each other.  Trust me, this is the stuff of nightmares!  If you commit in penny-packets your merge conflicts will be more coherent and less entangled.

If you use continuous integration to build your project, and you run unit and/or integration tests as part of that build, then you will get even more benefit out of using your version control tool and committing early and often.  The continuous integration system can use unit tests  to make an independent verification that every commit meets a certain set of criteria.  This knowledge can be very comforting to all involved in the project.

You may also find that you develop a rhythm while working this way.  You make a few changes, test them then commit them and watch the build pass.  While I have no data to say that this process makes you more productive, I can say anecdotally that it makes me more productive because I spend less time getting held up by common mistakes.