David Develops (Software)

It appears as though the Microsoft M.V.P’s that were called upon to advise on the technicalities of the forthcoming Entity Framework hit a little bit of a roadblock.

When I say “a little bit”, it seems as though Microsoft just point blank disregarded their warnings and recommendations in regard to creating OR mappers. It’s probably the first time I’ve seen this kind of scenario end with the technical advisors posting a warning and a general vote of no confidence.

I’d be lying if I didn’t say I felt a little disappointed that after making steps in the right direction and asking domain specialists for advice, that Microsoft entirely disregarded the advice of the specialists they consulted resulting into what seems like an unusable shipping product.

I’ve not attempted to use the entity framework in and form, but the technical criticisms in the vote of no confidence are quite explicit, and as a developer who makes extensive use of OR/M, if those criticisms are accurate (which is very likely) I’d certainly treat the entity framework with the same unfortunate disregard.

At least nHibernate isn’t broken!

There’s a very good argument for saying that the thing that makes or breaks a new programming language is actually the tools the work with and around it, rather than language features themselves.  If you ask the average programmer to guess the percentage of language features of their language of preference that they used on a daily basis, or even ever, I suspect many of them would respond somewhere in the 25-30% range. 

Programming languages these days are big.  By that I mean, programming frameworks these days are big.  Most people tend to not just use the language natively, but the selection of a preferred platform tends to be based on the features of the dominant framework available for that language.  As a simple statement this is neither here nor there, but it illustrates the point that the development environment, for a large proportion of its users, makes a language.  I’d argue that Visual Studio made Visual Basic popular, and that without it, it would probably haven’t stood a chance against Turbo Pascal and Delphi, even with all the clout of Microsoft.  So we rely on tools, and in honour of tools, here are a list of tools I find invaluable whilst developing in .NET.

JetBrains ReSharper

This is the king of all visual studio plug-ins.  Imagine it as a kind of, interactive FX cop while you work.  It offers background compilation, refactorings, stream lines existing visual studio functionality and basically makes you code better.  It teaches you things you didn’t know about the language and helps you improve your code quality proactively rather than retrospectively.  The biggest programming crutch known to man, and a descendant of the IntelliJ IDE for Java.  JetBrains have trials available and if you drop my name in you can get an improved trial period and a bit of a discount on purchases.  If I could take just one tool home, it’d be this.

Lutz Roeder’s Reflector

Ever thought that there was a bug in someone else’s compiled assembly?  Fancy a crawl around the internals of the .NET framework?  This is the tool for you.  Reflector translates the IL of a compiled assembly back in to C# and lets you poke around inside.  It’s very much read only, but if you ever think there’s a bug in something you’re not supposed to touch, you can prove it and code around it with the help of this excellent tool.

System Internals / Microsoft Debug View

I’ve written about the usefulness of this little application in the past.  Debug View lets you view the Windows Debug output stream in real time.  That’d be anything written using System.Diagnostics.Debug.WriteLine or the more traditional C / C++ equivalents.  Allows you to monitor an application built in a debug state in real time.  Perfect for debugging Windows services or other troublesome applications that you need to monitor whilst running during development.

Visual Studio Remote Debugger

If you have Visual Studio you actually already have this (the link above is to setup information).  It’s hidden away in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger (replace the visual studio version as applicable) and it allows you to attach an instance of Visual Studio to an application running on another machine.  Again invaluable if you’re writing distributed services and deploying to test servers, this application allows you to run your service or application on another machine, then connect to it using the visual studio debugger and break and step through your code as though it were on your local machine.  Great for when you deploy something to an integration test server, it fails, and you just can’t work out why without digging through the code in real time.

MbUnit and Rhino Mocks

Two for one, an xUnit derived unit testing framework, and Ayende’s mocking framework.  Unit test with confidence and unit test often.

ANTS Profiler

ANTS profiles your .NET applications at a level I’ve not seen in any competing products, giving you a line by line, method my method breakdown of execution time and code bottlenecks along with all the stats you could ever want to generate on a piece of code.  You really can use this to find horrible hidden performance issues in your code and fix them.

Honourable Mentions

Notepad++

Everyone has their own favourite notepad replacement utility.  This is mine.  I used Context for years but this is just better in every way..

Pro C# and the .NET 3.5 Platform

The only “giant programming bible” I’ve ever been able to read like a book.  Grab an E-book so it’s searchable and you’ll probably get more information than you could Google for.

These are just my personal preferences, and applications that I use on a daily basis.  Give a few of them a try and you’ll see your productivity increase and hopefully, your code improve.