Unhandled Exceptions

Background: Source Code Outliner Visual Studio PowerToy

Anyone who has watched any of my many screencasts or read my own list of tools that I use to enhance my Visual Studio coding experience knows that I am a big fan of the Source Code Outliner Visual Studio PowerToy (freeware, developed and released by Microsoft).

As shown at left, this Visual Studio add-in provides a treeview of the source file in your currently-active editor window.  It displays this in a standard Visual Studio tool window so that it’s dock-able, pin-able, collapse-able, and all the other -ables that the VS IDE lets us do with standard tool windows.

If you haven’t used it, you should start (since its free) but the best way to describe it is as either ClassView-lite or as a Document Outline window that also works for VB and C# source code files instead of just HTML, UI designer surfaces, etc.

Among other niceties, it allows you to single-click an item in the tree and have the editor window scroll as needed to display the declaration of the clicked tree item or to double-click a tree item and have the editor both scroll to display the item’s declaration and place your edit cursor at that location in the editor.

Essentially, it provides a convenient, at-a-glance way to visualize the elements in your currently-active editor window and quickly navigate from one to the next.

As shown in the following screen-caps, the tool window also offers the ability to filter the types that are displayed by selecting from a dropdown control to filter the contents of the tree or even typing partial strings into a textbox for rudimentary pattern-matching to filter the treeview…

Some Shortcomings of the Visual Studio Source Code Outliner PowerToy

Despite the fact that I love the thing, there are some aspects of its behavior that I really find myself wishing I could change or enhance…

Text String Pattern Matching

The first thing I find myself really wishing for is the same kind of ‘intelligent’ parsing of Pascal-cased identifiers that the CodeRush QuickNav window provides.  If you’re not familiar with this tool in CodeRush (as shown at left), it provides a list of identifiers defined within whatever scope you request (whole solution, current project, current file, current class, whatever) and provides you a filtering textbox that functions in a manner very reminiscent of the way the Source Code Outliner filter textbox works.

What the QuickNav filtering offers that the Source Code Outliner doesn’t is the ability to ‘intelligently’ filter based on a match between CAPITAL letters provided as a filter string and the Pascal-Case characters of any identifiers to be filtered.  As shown in the image, I have entered “RPR” (as capital letters) and the list has been filtered to reflect the only match in the list, “RemoveParentRegionIfExists“.  I’ve grown to depend on this kind of capital-letters-equal-Pascal-casing-parts-of-identifiers and I find I miss it terribly in the Source Code Outliner.

Method Signatures: Parameters

The Source Code Outliner only displays the data type for the arguments for each element within the tree.  This leads to nodes in the tree that look like this…

• DoWork (string, string, int)

I’m sure that the Source Code Outliner developers decided to only display data types for arguments in order to conserve space and prevent the text for each node from being ‘too long’ but if you have any method overloads in your source code, this leads to nodes that often look sort of like this…

• DoWork (string)
• DoWork (string, string)
• DoWork (string, string, int)

…which can get somewhat annoying to try to distinguish from each other when you see them all in the tree at the same time.

While not bad, I find I often want to choose whether I get this ‘concise’ version that just shows data types for the arguments or whether I want to see a more detailed version that shows the named parameters to each of the methods as in…

Method Signatures: Return Types

As with the parameters only showing data types in the Source Code Outliner, I find that sometimes I want to see return types from methods as well so that instead of elements in the treeview being limited to this…

• DoWork (string)
• DoWork (string, int)
• DoWork (string, int, string)

…instead I could see something like this…

• void DoWork (string)
• bool DoWork (string, int)
• Customer DoWork (string, int, string)

…or even this since I think I prefer seeing the method name on the far left so that it sticks out as my eye reads down the list…

• DoWork (string) :  void
• DoWork (string, int) :  bool
• DoWork (string, int, string) : Customer

Limited to VB.NET and C# source files

While the Source Code Outliner does an admirable job on .vb and .cs source files, its treeview remains sadly empty and the window sits idle when you find yourself in a .js file editing javascript.  Interestingly, because the remainder of the VS IDE still does a (comparatively) poor job of providing tooling for navigating javascript files, .js files are one place where I think I’d find the Source Code Outliner to be of even greater value to me in my work…that is if it actually worked in .js files, of course

Cannot Invoke Refactorings from the Treeview

Even as the Source Code Outliner provides a great at-a-glance view of the outline of your source, its only useful for low-level navigation and cannot be used as the basis to invoke even simple refactorings like ‘rename’ from within in.  Sure, I can use it to navigate into the actual source code and then invoke refactorings from there, but that’s not as useful as it could be.  Time and again I find myself saying “Now that I can see all of the methods in my class here in this nifty outliner, I really wish I could rename some of these methods from right here where I can see all of them at once“.

If You Are a Software Developer and You Don’t Like How Software Works…

…then shut up and write something better! .  My complaining about how something works in software is a bit like the fashion designer bitching that there aren’t any great new fashion ideas coming out lately — the power to change this is well within my grasp.

Introducing the DX_SourceOutliner Mash-Up

My solution to all these problems is to begin to develop my own DXCore-based Visual Studio Add-in that offers all of the same capabilities as the existing Source Code Outliner but also addresses the shortcoming listed above.

As shown in the preliminary UI mockup at right, its conceptually a sort of a mash-up between the filtering capabilities of the CodeRush QuickNav tool and the treeview display of the original Source Code Outliner.  The important points here are as follows…

(A) a textbox for entering filtering strings; respects the capital-letters-equate-to-pascal-cased-identifiers; the filter can be toggled on an off with the [ ]Filter checkbox and the [^] control can be used to collapse the rest of the filter panel to make more room for the treeview below

(B) types, accessibility, and scope toggles in a shamelessly ‘borrowed’ concept from the QuickNav add-in; at this early point, uncertain if all of these filters actually need to be present, but the UI paradigm (toggle buttons for each) is the intention here

(C) checkboxes for display choices for the items in the treeview; these may also evolve away from checkboxes to become so-called ‘toggle icon buttons’ as in the filter toggle buttons in (B) but its too early to be sure of this just yet

(D) Treeview display of code elements in the presently-active document; content and display characteristics are controlled by all the other controls in the tool window (items A, B, and C)

Call for Feedback

The amazing thing about this is that thanks to the efficiency of the DXCore abstraction on top of the VS extensibility API combined with the power of the CodeRush structural parser and code metadata facility, it only took me perhaps three hours last night to prototype this thing to the point where I’m satisfied that its a successful proof-of-concept and worth completing.

To be sure, there is still quite a distance between my prototype and a piece of software I would ever unleash on even my worst enemy, but the conceptual part is well on its way and the work ahead of me is starting to gel a bit for me now.  I’m imagining this as trying to remain a DXCore-dependent-only add-in so that it can remain available for those that don’t purchase the commercial versions of CodeRush and Refactor!Pro so it can be used by all, but we’ll see if I stumble upon some super-wonderful feature that I just have to add that conflicts with that goal as the development process proceeds.

Before I get too much further into this, I’d be very interested in people’s comments/feedback on this tool — any ideas for additional features, different ways to approach the problem, etc. would be very much appreciated at this early stage, just leave a comment on this post.

Let me know your thoughts~!

Its that time again — Developer Express has just released their next quarterly installment of their suite of Visual Studio Productivity Add-Ins, running the gamut from the commercially-offered CodeRush and Refactor! Pro to the completely freeware CodeRushXpress.  This means its also time for me to release the recompiled binary of the CR_ClassCleaner open source DXCore add-in for re-organizing your entire class file with a single keystroke, recompiled to function properly against the latest DXCore update.

Regular readers of my blog will recall that while I have absolutely no connection to the actual ClassCleaner project on Codeplex, I am a huge believer in the benefit it provides of not making me worry a bit about where I place members in a class file as I’m coding my way through the development process.  Disappointingly, each time Developer Express issues an update to the DXCore engine that underlies their Visual Studio add-ins, the former build of ClassCleaner ceases to work until recompiled against their updated binaries.  Because I have to do it anyway, I always rebuild the ClassCleaner plug-in binaries myself and because I’m such a great guy I also always make this updated binary available to anyone else who’s interested.

So without further ado, here is the updated CR_ClassCleaner binary recompiled against DXCore 2009.1.5.

Reminder to Check out CodeRushXpress

BTW, even if you aren’t a commercial customer of CodeRush and/or Refactor! Pro, you really owe it to yourself to go download the completely freeware CodeRushXpress add-in for Visual Studio from Developer Express.  If you are coding professionally (or, frankly, even as a hobby) and you value your own time at all, you’re literally stealing from your employer, your client, or even yourself if you’re coding in Visual Studio without some kind of refactoring tool. 

For 100% free, you can’t beat the value proposition that CodeRushXpress provides; for more details, check out this recent blog post from Mark Miller where he explains some details about what’s available for 100% free with the CodeRushXpress product — its really amazing that this can be had FOR NO MONEY AT ALL: CodeRush Xpress for C# and Visual Basic inside Visual Studio 2008

As always,  happy coding~!

Readers of this blog may recall that Eric Evans (author of the canonical book in the field and considered by most to be ‘the father of Domain Driven Design’) gave a presentation to the NYC DDD User Group (of which I am a regular member) several months ago.

At that time, many asked if the presentation would be recorded in video for those that couldn’t attend the meeting but were interested in the content.  I’m happy to announce that I just received word from the organizer of the DDD group that the video from this presentation has now been posted to the Domain Driven Design Community site and is now available for viewing.

If you are remotely interested in DDD as an approach to managing software engineering complexity in your work, then I strongly recommend that you take the time to watch this video; Eric has suggested that he’s probably not going to pursue either writing an entirely new book or releasing an updated edition of the first book, so this venue looks like your best bet for discovering the lessons and experiences that have shaped his current views on the content in the original book.

Happy viewing~!

For those who didn’t manage to attend the Agile Firestarter 2009 Event this past Saturday in NYC (details here), the videos from the first two sessions have now been posted to Vimeo for viewing at the following URLs…

• Introduction To Agile (with yours-truly presenting)
• Agile Estimation (with Steve Forte presenting)

Over the coming weeks, look for more videos of the other sessions including TDD, IoC, CI, and Refactoring as they are post-processed and come on-line under the Vimeo tag “agilefirestarter”.  If you’re curious about Agile, what it means to a software developer, and are interested in getting ramped up quickly on some of the concepts, this might be a great place to start!

Thanks (as always) to Alex Hung

All of these videos are the result of the diligent video-capturing efforts and dutiful post-processing work of the NYC ALT.NET group’s unofficial videographer, Alex Hung.  The community owes him a huge debt for all his hard work in capturing this content, organizing it, post-producing it, encoding it, and ultimately uploading it beginning so quickly after the event’s conclusion just this past weekend (thanks, Alex~!)

An Assembly History of NDbUnit

As some of you are aware, I have some time ago assumed the role of primary committer on the opensource NDbUnit project.  The history of this project is that it began with just two database ‘target’ types supported: Microsoft SQL Server and Microsoft OLEDB-supported databases.

All of this capability was wrapped up into the single assembly, NDbUnit.Core.dll that had hard binary dependencies only on standard Base Class Library assemblies that shipped with the .NET framework (System.Data.dll that contains the ADO.NET client implementations for SQLServer and OLEDB in this case).  Since a developer had to have the .NET Framework installed to be writing .NET software in the first place, this effectively meant that NDbUnit.Core.dll had a hard dependency only on other binaries that all adopters would already have on their computers.

Essentially it meant that all developers using NDbUnit would use the same assembly references regardless of what database ‘target’ they were working with.

Growing to Support Third-Party (non-MS) Databases

Due largely to the contributions of others, the NDbUnit project  slowly grew to work with and support additional, non-Microsoft database targets.  Today, in addition to the support for MSSQLServer and MSOLEDB, NDbUnit also supports the following third-party databases:

• MySQL
• SQLite
• SQL Server CE

I include ‘SQL Server CE’ here even though its (obviously) also a Microsoft database because it turns out that if you install Visual Studio and fail to check the box to include ‘mobile development support’, you don’t get the needed System.Data.SqlServerCe.dll assembly installed on your PC.

The trick will all of these third-party database targets is that they all require some third-party assembly in order for ADO.NET to interact with them.  And since NDbUnit is leveraging ADO.NET under the covers to interact with your database, NDbUnit needs these assemblies in order to work properly…

• MySQL (MySql.Data.dll)
• SQLite (System.Data.SQLite.dll)
• SQL Server CE (System.Data.SqlServerCe.dll)

The Trouble Begins…

The real issue at the core — no pun intended — of this trouble is that as originally conceived (and thus as was the case when I assumed ‘ownership’ of the codebase), all of the supported database targets were compiled into the single NDbUnit.Core.dll assembly.  When the only supported databases were SQL Server and OLEDB, this didn’t matter too much.  But as the number of supported databases grew and expanded to include non-Microsoft targets, the fact that all of this code was compiled into the single NDbUnit.Core.dll assembly meant that anyone wanting to use NDbUnit for one database target was required to take a dependency on all the database targets.  This results in the ungainly dependency graph shown here…

…and it effectively means that if you reference in the NDbUnit.Core.dll assembly, you also have to reference in all of the other third-party assemblies whether you want / need to use them or not.

Clearly not a very good ‘take just what you need’ story for NDbUnit.  Instead, the story became ‘all or nothing’ and for a project with a wide-variety of adopters intended to be useful in a wide variety of situations, clearly this was becoming a real problem.

And worse, its a problem that will expand as other database targets are added to the project (e.g., Oracle support is under construction right now) — any new database target support assemblies would need to be referenced by any and all NDbUnit users right along with NDbUnit.Core.dll.

…and Leads to a Fix!

The solution I have now introduced into the NDbUnit project (which frankly isn’t really all that ground-breaking) is to divide the dependencies into more database-specific assemblies.

Where previously all of the support for each different database target was incorporated directly into the single, monolithic NDbUnit.Core.dll assembly, now the core assembly merely contains the common interfaces and base classes that each of the database target-implementation classes depend upon.  The database-target-specific code has been moved into separate assemblies, one each for each of the supported database targets as follows:

Each of these NDbUnit client assemblies in turn depends on NDbUnit.Core.dll and exactly ONE (and only ONE!) of the other ADO.NET-supporting assemblies.

As an example, the following dependency diagram shows the assemblies needed for support of MySQL using NDbUnit.  Your test project needs only to reference the MySQL-specific NDbUnit client assembly (NDbUnit.MySql.dll), the common assembly NDbUnit.Core.dll, and the MySQL-provided ADO.NET support assembly, MySQL.Data.dll.

While the effect of this is that the NDbUnit-adopter has more separate assembly dependencies to manage when setting up their test projects, the benefit of this approach is that adopters of NDbUnit are now only required to take a binary dependency on the libraries that are needed to support just the database target that they are interested in working with rather than a dependency on all of the assemblies needed to support every conceivable database target that NDbUnit supports now and for the future.

Please also note that there is NO change in any of the namespaces with any of the types in NDbUnit that are being introduced with this refactoring, so all that is needed to update any of your projects to use this new assembly distribution model is to download the latest binaries (or get the code and build it for yourself), change your project’s references to whatever is appropriate for your database target, and recompile.  Your tests should still ‘just run’ as before.

Another Positive Side-Effect

One other side-benefit of this change in approach is that it now permits the versioning of the assemblies completely separate from each other.  A change in the NDbUnit MySQL client assembly won’t result in a (somewhat needless) version change for anyone NOT using MySQL (for example) and users can only bother to update their versions when changes are introduced in the libraries that support their specific database targets.

This will also help when introducing support for multiple DB target versions from the same vendor (e.g., Oracle 8, 9, 10, 11, whatever) in that each client support assembly can be considered a separate assembly and chosen by users as needed for their version of the database target.

Happy database testing~!

I know many are too remote from the NYC metro area to attend this event, but all day Saturday 6/27 some of us organizers in the local .NET community down here are holding an event we are calling the ‘Agile Firestarter’ for .NET developers interested in learning more about Agile software development techniques and practices.

The day will be a series of short introductory presentations on each topic followed by related ‘lab exercises’ done via pair programming to give attendees the chance to experiment with putting some of the techniques into practice in a collaborative environment.

For all the details including speaker list, agenda, logistics, and a link to the RSVP system, visit the following URL:

http://www.agilefirestarter.net

Because our venue has limited capacity, attendance is capped @ 60 persons MAX so if you are interested in attending, I would encourage you to RSVP sooner rather than later.  Registration opened this morning and there are already less than 50 slots remaining.  There is a nominal $8.00 fee that covers food and drink, but the event is effectively free of charge.

Attendance is open to any .NET developer interested in participating (regardless of any affiliation with any user group); if this event meets with success, it may be repeated again later in the year, but that’s just a hypothetical right now.

Hope to see you there if you can spare the time and are interested in a good learning experience~!

Announcement

Repeated here is the event announcement as it was transmitted to the local NYC .NET user groups…

Are you just starting out with Agile, XP or Scrum and need to get up to speed? Or do you know a thing or two about Agile but want to learn the basics so you can implement it in your organization? Then this Firestarter is for you. We’ll take you from 0 to 60 in 8 hours. Bring a laptop with Visual Studio 2008 Express edition or better for an all day hands on seminar led by some of the NY area’s Agile practitioners.

When: Saturday June 27th

Where:

Kaye Scholer LLP
425 Park Avenue
New York, NY 10022

Time: Registration and welcome 8:30am

Cost: $8 (to cover the pizza and materials)

To Register: http://agilefirestarter2009.eventbrite.com

Agenda:

• Registration and Welcome

• Intro to Agile  (Steve Bohlen)

• Agile Estimation (Steve Forte)

• Test Driven Development (Steve Bohlen)

• Pizza!

• Continuous Integration (Alex Hung)

• Refactoring (Mark Pollack)

• Dependency Injection (Mark Pollack)

• Retrospective Erik Stepp

• Wrap up

Register today, space is limited!  For more details, see: http://www.agilefirestarter.net

If you missed the April 2009 NYC ALT.NET user group meeting on Continuous Integration and automated builds, you can still check out the videos of the meeting on Vimeo here.

For this meeting, our usual videographer, Alex Hung, actually delivered the presentation himself so that camera work was by another of our group organizers, Yitzchok Gottlieb who volunteered to man the camera during the session.  Alex still gets the ‘nod’ for his tireless devotion to post-processing the recording and posting it for all to benefit from!

If you’ve been interested in Continuous Integration but not sure how to get started or even how to evaluate the (rapidly-expanding) collection of choices for CI servers out there today, I’d encourage you to check out the videos.

For those who couldn’t make the meeting, the videos of the March 2009 NYC ALT.NET user group have been posted for viewing on Vimeo here.  As usual, our group’s resident videographer, Alex Hung, is to be thanked for the effort of both capturing this video and post-processing it to get it ready for posting.

For the March meeting we were fortunate enough to be able to host a a high-powered guest speaker in the form of Jeffrey Richter, one of the founders of Wintellect and a great source of information about many of the underlying principles and designs of the Windows platform.

Jeff condensed his three-day seminar on multi-threading and performance tuning of Windows Applications down into a 1.5-hour talk with some Q+A at the end.  The meeting (and if you missed it, these videos instead) are a great chance to gather some pearls of wisdom from the master when it comes to writing multi-threaded, high-performance windows applications.  Jeff also digs into some examples of how to employ his PowerThreading Library to create asynchronous code that’s both easy to read and easy to write.

With today’s multi-core processors nearly ubiquitous, anyone trying to write any software to run on a (semi-)modern Windows operating system really needs to ensure that they are current on the topic of how to (efficiently and effectively) write multi-threaded code in .NET and Jeff’s presentation is a great jumping-off point for coming to grips with that world.

I have been MIA for about the past two months (on this blog, on my screencasts, and just about everywhere else).  Personal and professional obligations have kept about 100% of my attention lately but beginning today these situations have largely resolved themselves and so I should now be back to my regular (slightly) higher online profile.

New Dev Express Tools Release

For anyone who missed it, Developer Express has recently released the 9.1.4 version of their always-excellent and continually-improving Visual Studio Productivity Tools, CodeRush, RefactorPro, DXCore, and CodeRushXpress.  As is often the case (usually, except lately where I’ve missed the last one!), I am posting for convenience download the binary build of the open-source ClassCleaner add-in that is compatible with the recent DXCore release.

Since DXCore (and ClassCleaner) are completely free, you need not be a paying user of CodeRush + RefactorPro to leverage these excellent add-ins.  Since I missed the 9.1.3 release, I’m providing the binary that’s compatible with that one too, but there really isn’t any GOOD reason why anyone would want to use the older release of the DexExpress tools, so I’m recommending that everyone get the latest releases from DevExpress and use the corresponding latest ClassCleaner  build provided here:

ClassCleaner for DXCore 9.1.4

ClassCleaner for DXCore 9.1.3

CodeRush Xpress Now Supports VB.NET

As an aside, in case you are a VB.NET programmer (and as many will know, I used to be one myself before the siren-song of the curly-braces called me back to C# from my C++ roots), you may be happy to know that with the 9.1.4 release of CodeRush Xpress, there is now complete support for VB.NET as well as C# only (as had been the case when the product was originally announced/released last November at the PDC).

CodeRush Xpress is a 100% free Visual Studio Add-in that provides perhaps 40% (my number, not an official one) of the capabilities of the commercial CodeRush + RefactorPro products for absolutely ZERO money.  While I strongly feel that the commercial versions are entirely worth the investment, if you are a developer on a tight budget and cannot get your employer to spring for the full products, you are missing some serious FREE productivity tools if you aren’t at least considering using the CodeRush Xpress tool to your immediate benefit.  And with the VB.NET support now in the latest release, even that excuse now goes away.

Happy coding, everyone~!

Now that I have updated the NDbUnit library to support SQLite and SQLCE database targets, I have also just updated the Proteus UnitTest Utility library to offer support for these DB types in its wrapper around NDbUnit.

The new (latest) release is available from the Google Code Site or as a binary download or as source code, your choice.

Enjoy~!