Found an interesting work-around for signing 3rd party assemblies. This is just one of the pages that describes the technique, but I've seen in various places ...

http://scmay.wordpress.com/2008/07/17/assembly-generation-failed-referenced-assembly-does-not-have-a-strong-name/

and also a codeplex project that does it all for you

http://www.codeplex.com/Signer


E.g. Lets say the name of the third party DLL is myTest.dll.
Step 1: Dis-assemble the assembly
        ildasm myTest.dll /out:myTest.il

Step 2: Re-Assemble using your strong-name key
        ilasm myTest.il /res:myTest.res /dll /key:myTest.snk /out:myTestSN.dll

This code work perfectly to assign strong name.

for verification you can use following command,
sn -vf myTestSN.dll

An interesting article with 5 links to a good few articles:
http://www.codinghorror.com/blog/archives/001050.html

We are good at this!!

A good article on implementing singleton classes - the wrong and right ways to do it:
http://www.yoda.arachsys.com/csharp/singleton.html

I think this is something we need to think about more often:

http://c2.com/xp/YouArentGonnaNeedIt.html

I am sure we may have seen this before but I came across it again and thought we should revisit some of these things:

The Most Useful .NET Utility Classes Developers Tend To Reinvent Rather Than Reuse

Richard

Avoid use of Console.WriteLine in Nunit tests.  Instead debug the test with breakpoints to get runtime values.

Debug.Write can be used in TestSetup and TestFixtureSetUp to help trace errors (as nunit catches exceptions in these methods and it my not be easy to debug).

If Console.WriteLine or Debug.Write (or similar) is used in Nunit tests then they should only fire when an exception occurs or a test fails (this is to simplify the command line and cruise control build outputs) OR to provide helpful info on teh status of the test (eg database script being run) NOT to help with debugging.

Thanks,
Barry