I absolutely LOVE the extensibility of the DXCore Visual Studio API abstraction layer that is both available free from Developer Express as well as bundled with Developer Express’ commercial and (free) express Visual Studio productivity tools.  The ease with which they have made it possible to create Visual Studio add-ins that act as integral parts of their own frameworks is equaled only by the near-complete lack of anything approaching comprehensive documentation for the API their tools provide 🙁

Rant Over, on to the Tool…

As some people are probably aware, I was a ReSharper user for years before moving over to CodeRush and Refactor! Pro.  For the most part, I have been able to find allegories to nearly all of the functionality in ReSharper in one form or another in the Developer Express tools, but recently I decided that one refactoring that I had always found quite useful in ReSharper being missing in Refactor! Pro had becomeme so noticeable to me that I decided to do something about it.

As I’ve said before: “If you’re a software developer and find yourself complaining about how software works (especially if you’re actually working with a software explicitly designed to be extensible!), then rather than complaining why don’t you get off your butt and do something about it???”

So I did.

The Refactor_UpdateNamespace Plugin

The premise behind this plugin is actually quite simple: while working in Visual Studio, its quite common to need to move (usually via drag-and-drop) a class file from one project in the solution to another.  This can be a common practice for many reasons, but the one that most-often comes to my mind is that of doing TDD, realizing I need another class to participate in making my tests pass, creating it, and then using the very common move-type-to-file refactoring to get the class into its one separate source file.

Once you do this, you end up with the new source file in your test project (usually NOT where you want it) and with the same namespace as your test project (usually NOT the right namespace for the new class).  Dragging-and-Dropping the class file into another VS project can solve the first of these problems, but the second of there two problems (the wrong namespace for the new class) cannot be easily solved without manually editing the source file yourself.

ReSharper provides a ‘fix-namespace’ refactoring (not its actual name, I think) that permits you to ‘clean up’ the namespace of any class that isn’t a match for the ‘default’ namespace of your current project but unfortunately Refactor! Pro offers no such similar refactoring (that I could find, at least…sometimes there’s a refactoring lurking just slightly outside the range of normal discoverability, so I may have missed it somehow).  So, using the built-in DXCore API, I built my own in about 15 lines of code.  No, really.

Here’s what it looks like in action…

Usage

Usage is really simple: place the cursor in any namespace declaration and hit the ‘Refactor’ key (usually either [CTRL+`] or just [`] depending on whether you rebound it to another keystroke or not.  If the namespace isn’t a match for the ‘Default Namespace’ setting of the current project (as set in the Project Properties page in VS), you will be presented with the Update To Default Namespace Refactor choice as shown above.  Select it and the current namespace will be changed to match the project default.

That’s it.  Really.

If the namespace declaration is a match for the current project’s default namespace, you won’t see the Update To Default Namespace choice at all, since its not ‘valid’ at that point.

Note that due to the somewhat odd way that VB.NET seems to handle namespaces, this plugin in hardcoded to only function in C# language files.  Its a long story, but what it boils down to is this: the CodeRush ‘Project’ abstraction has a .DefaultNamespace property that returns the project’s default namespace (and is what I’m using internally to access the value to change the source code namespace when its invoked) but this property seems to always be an empty string when accessed under VB.NET projects and so there appears no way I can make this plugin work correctly under VB.NET.

Sorry, VB.NET users, you’re out of luck on this one.  If anyone knows a workable way to have CodeRush extract the default project namespace setting under VB.NET please let me know and I will update this plugin accordingly to work under VB.NET.

DXCore Wins Again: Dirt Simple To Develop AND Integrate

I really wish that Developer Express would put some coherent effort into documenting the DXCore, CodeRush, and Refactor! Pro API libraries in anything approaching a professional level.  The fact that I could develop this plugin and so easily make it integrated into the whole CodeRush/Refactor! Pro system such that you cannot distinguish it from a refactoring provided by Developer Express themselves in what’s quite literally 10-15 lines of code speaks volumes about how powerful this extension system actually is.  Or could be.

The single biggest challenge to my effectively developing this plugin wasn’t getting it started (a quite useful ‘new plugin…’ VS Wizard solves that for me!), registering it with the IDE (dropping it into the right folder just makes it load!), integrating it into the Refactor! Pro menu (setting a property accomplishes that!), getting the help tip you see above to display (another property setting accomplishes that too!) but was trying to figure out which 15 lines of CodeRush API calls I needed to write.

An Open Call to Developer Express

Developer Express, if you’re listening, DOCUMENT THIS API LIBRARY IMMEDIATELY.  The lack of documentation puts this thing on par with most OSS projects where the primary source of how-to and reference information is blogs and forum postings.  Phooey on you.  You’re literally shooting yourself in the foot by making this API so clearly powerful and yet so clearly unapproachable to all but the most dedicated developers with problems to solve.

You could easily have a hugely rich community ecosystem around these products but for some unfathomable reason you seem to neither want to document this stuff or support even a rudimentary directory of community plugins on your own site.  Its baffling to me that there seems no effort around promoting this hugely valuable differentiator for your product.  Your customer are (by definition) developers, for god’s sake — wouldn’t the fact that your tools provide tremendous ‘shoulders’ to stand on in order for them to develop extensions to their primary work platform (Visual Studio) be something that you’d want to leverage in more than a passing mention –?  I just plain don’t get it, but I’m not your Chief Strategy Officer so perhaps it makes sense to someone in your company but just not to me from outside looking in.

(continually) missed opportunity in my opinion.

Download the PlugIn

Anyway.  I said Rant Over.  This time I mean it.  You can download the binary of the plugin here.  I will probably move the source for it over to the DXCommunity PlugIns Site when I get a sec just because its so simple a plugin as to not warrant its own SVN respository and its probably more discoverable by more people it its located at that site.

NOTE: Unlike some of my other plugins that only require the freeware DXCore runtime to function, this one requires the commercial Refactor! Pro add-in be present in order to run since its leveraging some of that infrastructure to get its work done.  Actually, now that I think about it, I wonder if that’s really true…I wonder if the freeware CodeRushXpress would provide enough infrastructure to run this plugin….hmmm…

If anyone is running just the freeware CodeRushXpress and want’s to try this out, please do so and let me know if it works or not!

As usual, if you find any bugs/issues, whatever, please let me know by posting comments here on my blog and I will try to get them fixed.  Mean time, happy coding~!

UPDATE: bug discovered and download temporarily removed

See this comment for details.

UPDATE: bug fixed and new download available

The bug is now fixed and new download is available as mentioned here.