Unhandled Exceptions

The next installment of the Summer of NHibernate Screencast series is now available for general download!

In this session we explore the NHibernate SchemaExport class and start to exercise its ability to generate our database schema directly from our hbm.xml mapping files.  In addition, we touch briefly on some of the relative advantages of DDD (Domain Driven Design) and start to understand how this aspect of NHibernate can help us avoid having to place the database front-and-center in our development mind as we are refining our Domain Model in our overall software development process.

Some of the highlights from this session include:

• Overview of the SchemaExport class and its role in our development process
• Understanding the somewhat awkward API methods exposed by the SchemaExport class
• Interpreting the somewhat arcane arguments to methods of the SchemaExport class
• Controlling the names of foreign keys in our generated schema
• Understanding the limitations of the DROP capabilities exposed by the SchemaExport class
• ‘Tricking’ the SchemaExport class into creating VIEWs from our mapping files instead of TABLEs
• defining a database INDEX in our mapping files
• applying unique constraints to the database from our mapping files

As usual, comments, suggestions, feedback and constructive criticism are appreciated~!

I have just been proven wrong, and this happens so infrequently that it warrants its own blog post (kidding!)

In a number of the installments of the Summer of NHibernate screencast series, I have repeatedly made the assertion that when one makes a change to an embedded resource in their Visual Studio project, the developer has to explicitly select REBUILD for that project because a change to an embedded resource in a project isn’t considered by Visual Studio to be a change that will ‘trip’ the BUILD action into considering that the project needs to be recompiled.

In the context of NHibernate, this issue relates to managing changes to the .hbm.xml mapping files that my screencasts have recommended be managed as embedded resources in one’s Data Transfer Object project.  When working in the screencasts on tweaking the contents of these mapping files, I have repeatedly advised that the developer needs to take caution to remember to explicitly call REBUILD on the project that contains the mapping files because otherwise Visual Studio will not recompile the assembly for that project and the mapping file embedded resources will not be updated in the assembly.

THIS IS WRONG (sort of!)

An astute viewer sent me a comment that suggested that in at least one of the screencasts I failed to REBUILD this project and yet the updated mapping file changes were still properly updated in the assembly — suggesting that an explicit REBUILD was not required.  I was skeptical of this, but promised to investigate.  I have done so now and my investigation has turned up the following: Visual Studio 2008 does indeed now ‘properly’ consider a change to an embedded resource item as a condition for which it will BUILD the project.

This is wonderfully helpful and yet entirely stealthy — I can find no documentation, announcement, or change-log for VS 2008 that suggests this is a change from past behavior and yet it clearly is such.  Visual Studio 2005 definitely still evidences the behavior that I was indicating where you must explicitly invoke REBUILD on the project to get changes to embedded resources to be reflected in your compiled assembly.

I can see how this wouldn’t really make headlines for MS in selling updates to VS 2008 (e.g., "Rush out and get your Update to Visual Studio 2008 and reap the rewards of auto-building when embedded resources have changed!" is hardly as effective a selling point as "now with embedded designers for WPF!") but I would have liked to have heard at least something about this somewhere!

Mea Culpa

In any case, I clearly missed this and kept my old VS 2005-style of working without ever considering that it might have been ‘fixed’ in VS 2008.  Now I wonder how many other ‘habitual work-arounds’ I have in my arsenal are no longer needed either….

The prolific writer Arthur C. Clark once (famously) wrote:

"Any sufficiently advanced technology is indistinguishable from magic."

As software developers, we are presented just about daily with such ’sufficiently advanced’ technology — the world of what one could know about software engineering techniques, languages, frameworks, databases, compilers, etc., etc., etc. is just so vast now that no one person would ever be able to learn it all in a single lifetime (and since I’m a skeptic about reincarnation, we’ll have to assume that a single lifetime represents a hard upper-bound on the time anyone has to learn anything ).  When faced with such advanced technology (and here ‘advanced’ really means nothing more than ‘that which a person doesn’t yet have the knowledge, expertise, etc. to fully comprehend the details of), everyone will be faced (at repeated points in their career) with ‘magical’ technologies.

The real question I think is not "will I be faced with ‘magical’ technology in my career?", but more "what will I do when faced with it?".

Automatic vs. Automagic

As I see it, you have two choices as a developer when faced with such a thing: just use it and not care about what’s going on under the hood, or take the time to learn about what’s really going on.

The purist in me says that you should always choose the latter rather than the former, but the realist in me understands that this is not always practical or even possible.  The difference between these two responses to ‘magic technologies’ leads me to what I call the difference between ‘Automatic’ and ‘Automagic’ things in your software project.

Automatic: ’something just happens and the details are abstracted away from me and that makes my life easier but I know how and why this happens so I can effectively troubleshoot if there is a problem with the abstraction’.

Automagic: ’something just happens and the details are abstracted away from me and that makes my life easier but I have absolutely no idea how or why this happens so I can’t possibly effectively troubleshoot if there is a problem with the abstraction’.

All of this matters because as Joel Spolsky so famously reminded us all some time back, all abstractions are inherently leaky.

Up the Abstraction Hierarchy

The history of computer science can be reasonably thought of as the quest for ever-higher effective abstraction layers.  All modern programming languages are in effect abstractions over assembly language which is in turn eventually an abstraction over binary logic gates of 1s and 0s.  If we didn’t believe in the value of abstractions, we’d all be programming in code that looks like…

0001010101 0111 01011010111101 01101101 1011011 110000110110101010

…and we have to admit that this isn’t very expressive or efficient (at least not for me!).

But the question in the presence of all this really has to be: "how many of us could write code in even assembly language, never mind 1s and 0s ?"  Some, to be sure (and I bow at your altar), but the vast majority of otherwise effective programmers can’t (and shouldn’t have to).  This is a layer at the root of their abstractions that they just don’t need to understand to be effective software developers.

And why not?

The value of Abstractions

David Wheeler is often credited with the following quote:

"Any problem in computer science can be solved with one additional layer of indirection."

Taken out of context, this seems somewhat tongue-in-cheek.  But the entire less-frequently mentioned quote is actually more useful (and significantly less flippant):

"Any problem in computer science can be solved with one additional layer of indirection.  But that will usually cause another problem."

This full quote demonstrates the concept that every abstraction introduced actually represents a trade-off  — between the value the abstraction is designed to add and the cost of whatever new problem the abstraction introduces.

In general, we are accepting of abstractions that provide value well above the new pain they add to our lives; we accept that we cannot (easily) get at the underlying 1s and 0s in our code since the abstraction of coding in 3GL is both so rich and so water-tight that it rarely ‘leaks’ (too badly!) on us.  Interestingly, a lot of the failure of wider-spread adoption of 4GL (and 5GL) approaches can probably be traced to the fact the 4GL and 5GL abstractions ‘leaked’ too much for a lot of cases (which isn’t to say that these types of languages have no value, its just to say that their problem domain and their abstraction need to be very closely aligned for them to be appropriate abstractions to introduce into your work).

I hate ‘Automagic’ things: rule of thumb for survival in a highly-abstracted world

Generally, I hate Automagic things in my code.  I would venture to say that most professional developers who take pride in their work and want to genuinely understand why their software either works or doesn’t would say the same thing if asked.  But as we’ve seen, this isn’t really a true statement.  At the root of each layer of abstraction lies another abstraction in the stack and there comes a point of diminishing returns with understanding underlying abstractions unless we all want to say that to be a good developer today means we all have to be silicon-chip designers in our spare time .

So what makes an acceptable level of understanding of one’s abstractions?  I think it works like this (as a general rule): learn the guts of the abstraction layer immediately beneath where you are working.  If you’re in .NET and dealing with the CLR, understand the memory model on a PC, learn about the difference between stacks and heaps, understand the threading model in your processor, and make damn sure you understand how that hard drive works (seek times, etc.).

Why does any of this matter?

Because someone asked me the other day about the challenges of bringing a new dev into the team on a project that used NHibernate for O/RM and data access, Castle Windsor for DI container services, Log4Net for logging support, etc., etc.  The question was: can’t this person just start consuming the services exposed by these tools and not really have to understand what’s going on inside them to get started?

The answer (of course) is ’sure they can’ but that’s only a temporary stop-gap solution because until the person is able to transition from these things being ‘Automagic’ to just plain ‘Automatic’ the person is at a tremendous disadvantage in working on the project because these things are merely a single layer deep in the abstraction hierarchy for the project and they are going to stumble into their leakiness sooner rather than later — its just about guaranteed.

The latest installment of the Summer of NHibernate screencast series is now available for download.

I will warn potential viewers in advance that this session is heavily focused on techniques and approaches that tend to contradict most Domain-Driven-Design/Development practices so please don’t waste your time telling me this — I know it already .  Leveraging NHibernate to better support DDD principles is coming in the next session, I promise.

Instead, this session focuses on techniques, approaches, concerns, and implementation practices that support effectively leveraging NHibernate in situations where (for all kinds of really good requirements reasons) your database schema design occupies a position of primacy in the hierarchy of your design constraints.

In this session we dig into the use of the MyGeneration OSS code-generation toolset and understand how we can use it to completely slave our Data Transfer Objects and their related .hbm.xml mapping files to the design of our database schema, entirely freeing us from having to manually code and maintain these solution artifacts during our development process.

We also investigate techniques to avoid the inclusion of ’string-literal’ values in our CriteriaAPI and HQL queries so that we can get complete compile-time type-checking on all of the statements in our NHibernateDataProvider class if/when things change in other layers of our application (e.g., the database schema), making reacting to change and catching errors all the more simpler for us.

There isn’t a whole lot of new NHIbernate-centric content in this screencast as its more about how to use tools and techniques to drive NHibernate in certain kinds of application design situations, but hopefully people will still find it to be of value.

As usual, comments and feedback (and criticism!) are greatly appreciated.

I am pleased to announce that I have now posted for download the latest installment of the Summer of NHibernate screencast series.  In this series we explore NHibernate’s support for many-to-many relationships in both our data and our object model, understand how to interact with views, and investigate some ideas about how to leverage NHibernate’s ‘Component’ modeling to help us avoid the ‘primitive obsession’ anti-pattern in our object model.

I also refactor our tests and our data-access-layer to reflect the introduction of the new Name component to our Customer class.

For the record, I am indeed aware that the results of this refactoring as shown in the screencast (that leads to code like Customer.Name.Firstname) represents a clear violation of the Law of Demeter, but I didn’t want to complicate the object model during the screencast.  In a real-world implementation of the Customer class bolstered by the Name class as an NHibernate ‘component’, its likely that this would instead result in a Customer class that looked more like…

public class Customer
{

    //…

    public virtual string Firstname
    {
        get { return _name.Firstname; }
        set
        {
            _name.Firstname = value;
        }
    }

    public virtual string Lastname
    {
        get { return _name.Lastname; }
        set
        {
            _name.Lastname = value;
        }
    }

    public virtual string Fullname
    {
        get { return _name.Fullname; }

    }

    //…

}

…so that accessing the Customer.Firstname and Customer.Lastname properties would pass-thru to the Customer class’ internal Name instance and the Customer.Fullname property would be a read-only pass-thru to the same-named property of the Name object maintained by the Customer.  In this way, consumers of the Customer class need not be aware of the presence of the Name class within the Customer class at all but would still benefit from the ‘richness’ provided by the Name class’ behavior.

Of course, it also now dawns on me that if I had proceeded that way in the screencast, none of the NHibernateDataProvider or NHibernateDataProviderTest methods would have had to have been touched since in a sense the Customer interface wouldn’t have actually changed .  Just some thoughts to consider~!

Technical Changes

This installment also represents the first that incorporates a few of the technical changes that have been requested by various people in prior feedback:

• the file format has been changed to wmv (windows media, video) so that (as requested by some) it can be watched @ 1.5x speed in Windows Media Player (hey, whatever works for you –! )
• I’ve changed my VS IDE font selection from Courier New to Lucida Console; this change should result in the code in the editor being a bit easier to read without my needing to increase the point size at all (and take up too much more screen real estate)

As always, comments, feedback, etc. are appreciated.

I have received a significant amount of feedback on the content in the Summer of NHibernate screencast series that I have been producing and let me say a quick ‘thank you’ to everyone for offering your input — its great to hear what people are thinking about what I’m doing, how I’m doing it, and what their thoughts are about the relative merit of my efforts here.

But instead of being about content, this post is about the technical merits of what I’m doing (and how I’m going about doing it).  I’ve now received enough feedback on this stuff that I feel like I can adequately organize it into a few repeating themes and I wanted to get some thoughts from the consumers of the screencasts about them before I consider making any changes…

Video Resolution

I have received a number of comments that my choice of 1280×1024 is ‘needlessly high-res’ for the content.  Perhaps the most public of this criticism comes from Scott Hanselman in this post where he’s kind enough to help publicize the work I’m doing with these (thanks again for the PR, Scott — my viewership/downloads have increased substantially since you and others have mentioned my efforts over here and that’s really great to see) but also mentions that he is suggesting that I reduce the resolution of these to either 1024×768 or even (gasp! ) 800×600.

Now, its not at all clear to me that anyone can effectively use Visual Studio at anything as low-res as 1024×768 even with the ’side-panel’ areas unpinned,  but what does everyone think about whether the videos could be recorded at this resolution?  My feeling is that there would be way too much scrolling going on for this to be effective.  This is my chief complaint with the otherwise valuable dot-net-rocks-TV stuff — that the huge amount of constant scrolling (both horiz and vert) in that series makes it very difficult to really follow what’s going on when the speaker is typing.  Scott, I think one of my recommendations to you would be to stop recording things at 800×600!   But reducing the resolution would help reduce the size of the downloads to be sure.

The other problem that I have with this is that I really am creating this content for internal distribution and reuse so if making it more download-friendly reduces its effectiveness for its internal purposes too far then I’m going to have to so ‘no’ to any change that does that of course.

But another comment I did receive was that "I have to play these on a high-res monitor".  So that I’m not a hardware snob (I have a pair of 24-inch flat-panel displays @ home), I don’t want to intentionally limit anyone from being able to view this content, but in today’s day and age is it unreasonable to assume that any serious developer would have a larger-than-SVGA-display at their disposal…?

Thoughts?

Video File Format

Another recurring theme is that people are asking for wmv (Windows Media - Video) format files instead of avi (Audio-Video Interleaved) files so that they can play them at 2x (1.5x ?) speed in Windows Media Player.  Apparently wmv files can be played at different speeds than recorded whereas avi files cannot.

I have to confess that until recently I never even knew you could play media @ 2x speed in Windows Media Player, so this never crossed my mind when choosing AVI as the file format.  I guess that playing screeencasts or podcasts at 2x speed must the the rich-media equivalent of speed-reading and although I don’t want to draw conclusions about what someone gets out of this kind of stuff @ 2x speed, I’m inclined to believe that its the A/V equivalent of Nicholas Carr’s Is Google Making Us Stupid? hypothesis .

None-the-less, if this is something that people are interested in, I suppose I could do it; what are the overall opinions on this?

I look forward to everyone’s input as always.

I’m happy to announce that the next installment in the Summer of NHibernate screencast series is now available for general download from the main Summer of NHibernate site.  This session was actually recorded in the middle of a raging thunderstorm that passed thru New York City so if you listen closely to the audio you can perhaps pick out the booming of thunder at certain points in the recording; hopefully its not too distracting .

That same storm actually temporarily knocked power out in my house for about 15-20 seconds and I was only able to keep recording thanks to the battery in my laptop — I guess there’s a good argument for not trying to record these on my desktop PC .  If you watch closely, about 42 minutes into the screencast I loose my Ethernet connection and the network icon in the system tray pops up to tell me — that’s my 100-mip switch going dark for about 30 secs before power came back up properly.  It wasn’t annoying enough to actually re-record that section so I just left it as-is.

Anyway, in this session we spend some up-front time evolving the way our NHibernateDataProvider class handles NHibernate session management to allow it to properly support our needs to do lazy-loading, separate the concern of creating sessions themselves out into a new NHibernateSessionManager class, and push the responsibility for creating sessions up into our test methods themselves so that they can properly manage session life-span at that level.

After we take care of those housekeeping chores, we move on to demonstrate querying across child collections in 1:many relations using both HQL and the Criteria API and then also spend some time digging into understanding the different ways that both query platforms support returning distinct objects from queries.

As always, comments, feedback, input, suggestions, and general criticism are appreciated from all.

Building APIs that provide a so-called fluent interface seems to be all the rage right now in .NET development and I will be the first to step up and agree that in many places there is merit to this approach — done right, it can provide clarity and value to classes and make the methods and properties on them more discoverable to developers unfamiliar with them.

The other day I was reading a blog post (sorry, I don’t recall which one else I’d provide a link) that suggested that you could improve the readability of your unit tests by introducing a fluent interface to your objects that would make it easier/simpler/more readable to set them up to participate in the unit test.  On its surface, this seemed intriguing to me until I was presented just the other day with code from someone who clearly took this idea to a ridiculous extreme.

Take a look and let me know your thoughts (note I have intentionally simplified this example for the sake of this post from the more complex context of the actual problem)…

The System Under Test (SUT)

Let’s assume we have a Customer class as so…

    public class Customer
    {
        private string _firstname;
        private string _lastname;

        public string Firstname
        {
            get { return _firstname; }
            set { _firstname = value; }
        }

        public string Lastname
        {
            get { return _lastname; }
            set { _lastname = value; }
        }
    }

Nothing at all odd going on there.  Now let’s assume that as all good developers do, we now want to write a unit test that ensures we can create a customer, set its first and last names, and have those same values returned to us (note that I am intentionally condensing this test down into a single test when in fact each of these things really should be tested independently of each other in separate tests).

The Traditional SUT setup

This is probably the traditional way to code this test…

[Test]
public void CreateNewCustomerTheLongWay()
{
    Customer customer = new Customer();
    customer.Firstname = "Steve";
    customer.Lastname = "Bohlen";

    Assert.IsNotNull(customer);
    Assert.AreEqual("Steve", customer.Firstname);
    Assert.AreEqual("Bohlen", customer.Lastname);
}

Extension Methods

The developer in this case however decided that a fluent interface for the Customer class would help facilitate easy-to-read tests and make it simpler to set up instances of the Customer class to be used in the testing.  In order to not ‘clutter up’ the actual class definition for the Customer itself, this developer authored some C# 3.0 extension methods to facilitate testing the Customer class as so…

public static class CustomerExtensions
{
    public static Customer WithFirstname(this Customer customer, string firstname)
    {
        customer.Firstname = firstname;
        return customer;
    }

    public static Customer WithLastname(this Customer customer, string lastname)
    {
        customer.Lastname = lastname;
        return customer;
    }
}

This little sleight-of-hand of extension methods allowed writing the same tests as above leveraging the ‘fluent interface’ to set up the Customer instance in a brief one-liner as so…

The Fluent-Interface SUT setup

[Test]
public void CreateNewCustomerUsingFluentInterface()
{
    Customer customer = new Customer().WithFirstname("Steve").WithLastname("Bohlen");

    Assert.IsNotNull(customer);
    Assert.AreEqual("Steve", customer.Firstname);
    Assert.AreEqual("Bohlen", customer.Lastname);
}

While as mentioned I do agree that fluent interfaces to the methods and properties of classes can be a good thing (tending to increase the signal-to-noise ratio in code), this is (to me) clearly a case of a solution in search of a problem when in-line property-initialization could be used to accomplish the exact same thing (setting up the Customer object for the test in a terse one-liner) as in…

SUT setup using in-line property-initializers

[Test]
public void CreateNewCustomerUsingInlinePropertyInitialization()
{
    Customer customer = new Customer() { Firstname = "Steve", Lastname = "Bohlen" };

    Assert.IsNotNull(customer);
    Assert.AreEqual("Steve", customer.Firstname);
    Assert.AreEqual("Bohlen", customer.Lastname);
}

What’s more Clear?

Its not at all clear to me that the fluent-interface-based line of…

Customer customer = new Customer().WithFirstname("Steve").WithLastname("Bohlen");

…is any clearer at all than the in-line property-initialization version of…

Customer customer = new Customer() { Firstname = "Steve", Lastname = "Bohlen" };

…and the non-extension-method version doesn’t rely on maintaining the guts of the ‘fluent interface plumbing’ at all.  Note that its also possible to put the meat of the Fluent Interface code into the main Customer class definition too — extension methods were just chosen by the developer in this case to avoid ‘cluttering’ the Customer class with the fluent interface plumbing (return this, etc.) but this is a matter of taste more than anything else.

Summary

This isn’t intended as an indictment of fluent interfaces on objects since as I mentioned in the beginning I am generally a fan of this style of exposing an API in many cases.  This  is instead an indictment of the "use the paradigm that’s most popular today even where other more appropriate techniques are…more appropriate " style of development where the bandwagon seems to get trotted out in all kinds of unnecessary places and as a result ends up polluting an otherwise good idea with its own inappropriate usages.

I’m happy to announce that the next installment of the Summer of NHibernate screencast series is now available for general download.

In this session we…

• dig into NHibernate’s support for modeling FK-relations between tables in our object model by adding collections that contain other objects
• explore the concepts of Lazy loading and how NHibernate uses proxy objects to defer loading entire deeply-nested object graphs until we ask for them

Unlike some of the immediately-prior sessions, this session contains a bit more Powerpoint content and a bit less interactive coding.  As this is our first foray into the quite complicated (and powerful!) universe of NHibernate collection modeling and mapping, there is a (relatively) large amount of new concepts that need to be introduced to lay the groundwork before we can start doing more complex coding exercises with collections and relationships in subsequent sessions.

In addition to understanding and demonstrating the mechanics behind Lazy Loading, this session also provides an overview of the different collection types supported by NHibernate (Sets, Lists, Bags, and Maps) and also covers how we properly ‘escape’ SQL reserved words when they show up in our .hbm.xml mapping files.

As always, comments and feedback are welcomed and appreciated.

As anyone who knows me is well-aware, I am a confirmed tool-addict.  If there is a utility, framework, add-in, add-on, or plug-in I want to have read about it, tried it, evaluated it, and decided for myself whether its worth keeping in my developer’s tool belt.  As a professional software developer, I’m unashamedly  and unrepentantly lazy:if there is a tool I can use that saves me time, effort, and energy then I want to be using it.

Visual Studio Professional is certainly the gold-standard of IDEs today as well it should be (at least for .NET development) but let’s face it: Visual Studio 2008 offers what is significantly the same developer experience as Visual Studio .NET (2002) provided.  Sure, there are a  bunch more features, the graphics now sport more curves and gentler lines , the debugger is certainly much-improved and (is this good?) there is now an integrated designer for Windows Workflow — but fundamentally there has been an evolutionary rather than revolutionary set of changes made to the primary developer toolset offered to .NET developers over time.

Of course, if you’re like me and consider the introduction of the Office 2007 ribbon UI to be an abominable layer of indirection further separating me from the tools I need to apply formatting to my MS Word document quickly (why, oh why does printing the current document take 5+ clicks now?…and how is that progress??), then perhaps the consistency of the overall Visual Studio development experience is actually a positive rather than a hindrance.  For example, just try to imagine what the debugger ribbon would look like and how hard that could have been to use productively if the ribbon UI metaphor had found its way into Visual Studio 2008!

So the bottom line is, if you want revolutionary change in your development experience in .NET, you’re going to have to look outside the Redmond-shaped box.  Fortunately, to give Microsoft credit where its due, Visual Studio is quite extensible (though hard in earlier versions, its gotten much easier in later versions) and they have done an effective job spawning and shepherding the creation of a pretty comprehensive ecosystem of third-party Visual Studio add-ins including many commercial and many open source.

With the (heartening) wide-spread interest in the Summer of NHibernate screencast series that I have been making available, there has been some interest expressed in understanding more about some of the tools that are being used in my IDE in the series.  In response, this post is a catalog of those tools (both OSS and commercial, and in no particular order) upon which I presently depend to get my work done and some reasons why I chose them over other options that may provide similar capabilities.

Since I don’t want to get into fights with people about what’s "open source", what’s "commercial", what’s "non-commercial", etc. I have identified each tool by the only thing that truly matters in all this: "no fee" or "payment required"

	Source Code Outliner (no fee) First up is the Source Code Outliner Powertoy on CodePlex and provided by Microsoft.  Like the built-in Visual Studio "Class View" window without most of the overhead (Class View Lite?) and only displaying what’s in your currently-active file in the editor, The Source Code Outliner offers the same kind of experience the "Document Outline" window provides for HTML, the WinForms editor, and other types of documents. Why Microsoft didn’t just fold the Source Code Outliner’s capability into the "Document Outline" window to make that window work when a source code file was active is beyond me.  Instead, the "Document Outline" window just goes blank when you’re in a source code file and you have to resort to this little add-in to get something to look at that’s less-visually busy than Class View. Light-weight, quick, and painless, makes me never have to look @ Class View (for just navigation) again.
	DXCore Visual Studio API Abstraction Framework (no fee) When the great team at Developer Express created CodeRush and RefactorPro! (see later listings for each) they realized (correctly) that the VS API was a god-awful mess to navigate and develop against.  To make their own work on their own products more of a RAD experience for their own staff than the hack-and-slash typically needed to wrestle with the VS API, they developed an abstraction library atop the VS API and named it DXCore. To foster a larger community of add-ins for Visual Studio, they released this library of utilities to the community at-large and invited people to build DXCore-based add-ins for Visual Studio (of which there are many available on the Internet at-large and several are in this same tool list here). Even though Microsoft has made great strides in making the process of developing against the VS API much simpler than it used to be, there is still tremendous value in the DXCore library as it makes it trivially simple to build a VS add-in…in fact, when you install it into VS, it actually adds a New Project template for a DXCore project that makes even getting started building your own a dirt-simple process (see figure @ left). Note: If you want to get a jump-start on producing your own DXCore plug-in, a great primer is the DotNetRocks TV episode from a while ago called Mark Miller works the DXCore (epispode 5, if you can believe it from way back in 2006).
	CR_ClassCleaner DXCore Plug-In (no fee, DXCore required) If you’re like me and you like to both have your class source code well-organized and at the same time are annoyed at having to remember to scroll back up to the top of your class just to define a new field in the ‘right’ place, then the DXCore CR_ClassCleaner plug-in is for you. ClassCleaner allows you to add code to your class (methods, fields, properties, enums, constants, whatever) and have ClassCleaner properly reorganize your class for you with a single keystroke (the keybinding of which you control when you configure it).  This gives you the freedom to just add a new method, etc. anywhere in your class and have ClassCleaner properly relocate it within the class’ source file when you invoke it — no more jumping around in your source file before you add a method or a field to ensure adherence to some (arbitrary!) code-organization standard (preference ). ClassCleaner provides a completely configurable order of the elements that you want it to relocate in your class source file, offers options to either ‘organize-with-regions’ if you’re like me and prefer #region tags in your files or ‘organize-without-regions’ if you think that code-folding is evil.  So that your whole team can use the same ClassCleaner settings, ClassCleaner supports importing and exporting its settings so that all of your team’s classes can be organized the same way (and so that running ClassCleaner on existing code doesn’t cause all kinds of trouble when you DIFF your code against your buddy’s before merging/committing it ).  A note (WARNING) about ClassCleaner: Even though the download page says it has been ‘updated for DXCore 2.5.1′ (which is quite outdated) it works fine under the 3.0.x DXCore release required for VS 2008.  However, to get this to work you must download the CR_ClassCleaner source code rather than the compiled binaries, remove the references in the project to the outdated DXCore 2.5.x libraries, add references to the newer 3.0.x DXCore libraries (available on your computer after you install DXCore 3.0.x), and then recompile the plug-in against the 3.0.x DXCore libraries.  After all that, CR_ClassCleaner works wonderfully against DXCore 3.0.x in both VS 2005 and VS 2008.  I have absolutely no idea why the author hasn’t bothered to recompile the thing against a newer DXCore version, but since the source is available, you can follow this process to easily do it yourself.
	CodeRush and Refactor! Pro (payment required) Mentioned earlier and featured pretty prominently in the screencasts are a pair of tools without which I really feel I would be doing software development with one hand tied behind my back: CodeRush and Refactor! Pro by Developer Express. CodeRush is a hyper-powerful and intensely flexible code templating engine that is perhaps best described as ‘code snippets on steroids’.  Offering templates and keybindings to do eveything from stubbing out a new unit test method to wrapping an entire code block in a try-catch-finally construct with the press of just a single key, CodeRush is a completely new way to author code that is a godsend to anyone who is as inaccurate a typist as myself .  And if you are somebody who routinely switches back and forth between projects in C# and projects in VB.NET, CodeRush is almost a necessity since the same keystrokes work in BOTH languages allowing you to become familiar with just the keystrokes and let CodeRush abstract away the language differences (people like me who do this often are fond of saying "I don’t code in VB.NET or C# — I code in CodeRush!". CodeRush also offers a huge range of much less-hyped features including built-in (and completely customizable) code metrics including CC, SLOC, and others as well as a tremendously more-powerful replacement for code navigation from search results (including a ’semantic search’ that finds matches not based on text (e.g., variable names) but instead based on actual variable instances that has to be seen to be believed). Even though the hot refactoring tool du-jour mentioned in all the posts these days seems to be JetBrains Resharper, I personally feel that Refactor Pro! is at least as good in most areas and a lot better in many others.  Where Resharper insists on showing me a hyper-annoying 1990’s style dialog-box every time it wants me to interact with it, Refactor Pro! has its UI completely integrated into the actual code editor window itself, offering me a visual preview of the effects of the refactoring that I’m about to apply to my code.  This provides a completely different style of interacting with the tool than the step-1, step-2, step-3 wizard approach of something like Resharper…and Resharper cannot even begin to touch the CodeRush functionality at all.  Even though Resharper has a relatively weak templating engine, its nowhere near as powerful or flexible as what CodeRush provides. Admittedly some of this is personal preference, but the combination of CodeRush and Refactor Pro! is pretty much unbeatable for the US$250 they are asking for the pair when Resharper wants that for what is basically only a refactoring tool. Developer Express offers trial downloads (CodeRush, Refactor! Pro) that usually last about 30-45 days which is plenty long enough for you to get hooked .  At the time of this writing, it looks like the present eval versioons expire September 1, 2008 (which is about the official end of summer). Some points: Use the CodeRush dynamic interactive keystroke ‘coaching’ window — its worth its weight in gold when learning the product.  Also, ensure you check out some (or all!) of the training videos Developer Express offers as they provide some really good overviews of the products too (though some of them are demo-ing older iterations of the products, they are still valuable as a learning tool).
	GhostDoc Automated XML Comment-Authoring (no fee) If you always wanted to write XML code comments (for use in post-compile code-documenting authoring) but could never bring yourself to take the time to actually write them (or maintain them!), then GhostDoc is for you. With a right-click and select of ‘Document this’, GhostDoc will reverse-engineer an entire collection of syntactically-correct XML code comments for you (which you can then refine if you are dissatisfied with the results of the tool). You will be pleasantly surprised by how often GhostDoc is perfectly able to deduce the right comments to add from nothing but the method name and its signature — for example, its more than capable of determining that a method called GetCustomerById(…) should have the comment "Gets the Customer By Id" added as a comment.
	CR_Documentor DXCore Plug-In (no fee, DXCore required) After using GhostDoc to create your XML code comments and then refining them a bit by hand, you might want to know what they are going to look like when eventually compiled to HELP content.  Before CR_Documentor, your only choice would be to actually build your app, fire up SandCastle, compile your help content, open it up, navigate to the topic, and take a look. But with the CR_Documentor plug-in for DXCore, you can preview your XML code comments immediately right from within the VS IDE without any of those steps required.  Recently updated for VS 2008 and moved to Google Code, this plug-in is a must-have for anyone serious about maintaining the XML code comments in their codebase.
	DocProject SandCastle Help File Processor (no fee) If you have ever tried to wrap your head around the 150 or so parameters and 80-90 steps required to use SandCastle to convert your extracted XML code comments into a usable HELP repository, then you should stop all that craziness right now and go download DocProject for SandCastle immediately. Although a brief glance at the DocProject site might lead you to believe that its own documentation is worse than that of SandCasltle itself , don’t despair — the site and related documentation is more complex than it needs to be because there are just so damned many choices this thing offers! if all you want to do is compile your XML code comments into the default DocProject website output, a simple compiled HTML help file (.chm) or another of the more common output formats, just download it, install it, and create a DocProject project in your VS solution and hit F6 (that’s BUILD in case you changed your default VS key mappings ) — this thing (despite its apparent complexity) just works — and well.  Trust me.
	TestDriven.NET Unit Test Runner (payment required) After all this time still one of the best VS unit test runners on the planet, TestDriven.NET can probably be credited with being one of the primary reasons that Unit Testing has managed the penetration into the .NET developer world that it has. Its hard to remember back this far with all the VS-integrated unit test runners out there today — even Microsoft’s own integrated runner in VS2008 — but before there was TestDriven.NET, running a unit test meant launching a separate unit test runner outside Visual Studio, loading your compiled assemblies into it, and clicking ‘run tests’.  Running tests again meant doing all that again…and god help you try to attach the VS debugger to the test-run process to troubleshoot a failing test! TestDriven.NET’s ability to reduce (if not eliminate!) most of the friction that used to be involved in running unit tests with any frequency at all has been often mimicked, copied, duplicated, and imitated but the good old stand-by still remains as a glorious example of a neat little tool that does one thing and still does it tremendously well.
	MbUnit Unit Test Framework (no fee) Originally started by a developer who now works for Microsoft on the PEX project, MbUnit (originally ‘Much Better Unit" — no, I’m not kidding about that) is essentially everything you have come to know and love about NUnit with a bunch more stuff to make the harder stuff easier. While MbUnit 3.0 is in alpha right now, the 2.4.x latest RTM release is dead-stable and highly reliable for use in production projects (I have a firm non-beta policy about anything that I use in my real-world work and this obviously precludes using any alpha software either ).  MbUnit 3.0 looks like it will be an awesome toolset and I look forward to its release, but I’m going to stay right where I am with 2.4 until 3.0 is ready for me.
	Rhino Mocks Mock Object Framework (no fee) A product of what I consider to be one of the most prolific .NET developers on earth (when does Oren actually sleep?), Rhino Mocks is one of the most useful mocking frameworks I have come across and I consider it essential to being able to effectively unit test anything but the most trivial of software development projects. If you’re serious about unit testing, the you need a mocking framework and if your serious about your mocking framework then you need Rhino Mocks.

I hope this post helps provide some insight into both what my tools choices are and why I selected them.

Happy coding~!