Using NUnitForms with NUnit Framework 2.2.9

NUnitForms has been compiled to work with NUnit framework library 2.2.7. However, NUnit have released a new framework which can be made to work with NUnit 2.2.9 quite easily.

By default, if you put NUnitForms and NUnit Framework 2.2.9 into the same project, you will get the error message

Could not load file or assembly 'nunit.framework, Version=2.2.7.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

along with a further error

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

However, you can use NUnitForms with NUnit 2.2.9 if you get the test project to perform some assemble redirecting. In your test project, create an app.config file and add the following XML to redirect NUnitForms assemble to use the NUnit Framework 2.2.9 assembly:

<?xml version="1.0"?>
<configuration>
  <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
              <assemblyIdentity name="nunit.framework" publicKeyToken="96D09A1EB7F44A77" culture="neutral"/>
              <bindingRedirect oldVersion="0.0.0.0-2.4.0.2" newVersion="2.4.0.2"/>
          </dependentAssembly>
      </assemblyBinding>
  </runtime>
</configuration>

Recompile and run your NUnitForms tests and your working :)

Project Startup Guidelines

There is such a diversity of projects that a developer can work on, it's very hard to know if you've started doing things the correct way. A startup checklist is a good place to start but they can be hard to come up with - then someone sent me a link to Patrick Cauldwell's blog which is an excellent account of items that should be considered when starting/working on any project. Well done Patrick - it's far too easy to steal this and adapt it for your needs but many of the disciplines in there excellent. It's well worth a read

One item that caught my eye whilst reading though was "only the public interface should be public". When using test driven development, you can end up making methods public purely for test purposes. This is not a good idea and as Patrick suggested, you should take advantage of the InternalsVisibleTo attributes which allows you to test private methods from test assemblies. Very useful and very easy to setup. I'll post on this technique later.