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 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~!
See this comment for details.
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.
Awesome idea for a plugin. I am currently running CodeRushXpress 9.1.5 and there does seem to be a problem with the express version. It only appears to replace the part of the namespace the caret is in with the default namespace (as opposed to replacing the entire namespace).
For instance, suppose I have a default namespace of MyProject.Domain, and I have a class in the namespace MyProject.Dom|ain.Tests (the | is the caret). When I use the refactoring I get MyProject.MyProject.Tests. However if I start with MyProject.Domain.Te|sts then the result is MyProject.Domain.MyProject.Domain.
Actually, that sounds more like a bug in my implementaion rather than anything to do with CodeRushXpress per-se.
I’m using a CodeRush API call called CodeRush.Selection.SelectWord() to select the text to replace and from your description I think I didn’t do enough testing on whether that’s a viable way to select the entire namespace string when there is a . delimiter in the namespace (as most people often have).
From your description, I’m guessing that the CodeRush.Selection.SelectWord() function ‘respects’ the ‘.’ as a ‘word boundary’ but I only tested it on single-word namespaces and so was expecting the ‘word boundary’ to be only whitespace.
So the good news is that it sounds to me like the freeware CodeRushXpress *will* permit you to use the plugin but the bad news is that this evening when I get home I need to fix this bug and change the way it selects the namespace text to replace so that it works property with the (all too) common use of the “.” character in namespaces.
That’s what I get for a rush-to-market strategy in order to gain first-mover advantage in the highly-competitive open-source-DXCore-plugins market 🙂
Mean time, I’m taking the download link down to prevent others from bothering until 1.0.1 is re-released…
Sorry, world, that’s what I get for using an API that’s poorly documented to build an app without any viable way to unit test it~!
I tried this out and it does exactly as you state; however, I was hoping it would support the sub folder and not solely use the default namespace. For example, if I have a class library with a default namespace of ExampleLibrary and I add a folder named Exceptions, when I move a file over from my test project into the Exceptions folder I’d like the namespace to update to ExampleLibrary.Exceptions.
I’m not sure if the R# refactor you spoke of does this or not, but it would be a good addition to this refactoring. Since C# uses this default behavior when you add new classes it makes sense to me.
Other than that it works fine. You may want to put a Built with DXCore version 9.1.X or something on here. It didn’t show up until I updated my DXCore to 9.1.5 from 9.1.2 (I know I was behind on my test machine). I was using the licensed version of R! Pro so I can’t answer the free DXCore question for now.
That’s actually a really good idea…I’m not certain if the R# version of this refactoring actually does or doesn’t respect that (the appending of the folder structure into the namespace when ‘fixed up’) but I can certainly see how that would be of tremendous value in *this* implementation.
Score another one for community feedback; thanks for the idea and I will explore how best to incorporate this into the refactoring. My best initial guess is that it will involve some path-parsing of the FQ path to the source file and appending it to the default namespace from the project settings.
Hey Steven – excellent idea for a plug-in – can’t seem to find it on code.google.com (yet) unfortunately 🙁
Need an idea for another one? You seem to be on a roll! 🙂 Do you ever wish you could have the Solution Explorer show you the file you’re currently working on, right now? I know there’s an option “Track active file” – but that just causes way too much commotion when I move around my files being edited in VS.
But at times, I need to see where in the project hierarchy that file is that I’m working on. Everything I found so far is god awful macros – slow as molasses, flickering like crazy – no good – period.
But a nice, slick DX plugin might just do the trick! 🙂 Well – got a weekend to spare? 😉
[…] Comments Marc Scheuner on Refactor_UpdateNamespace v1.0 Releasedsbohlen on Refactor_UpdateNamespace v1.0 ReleasedMike Wood on Refactor_UpdateNamespace v1.0 […]
FYI, the behavior you suggested has now been folded into the new release (that also contains the fix to @Harry S.’s reported bug).
I agree that the existing implementations of ‘dynamic tracking of active file in solution explorer’ tend to be pretty clunky; I’m pretty sure that there is already a VS addin (PowerTools(?) or something else i cannot recall right now) that offers ‘right-click-on-tab-and-pick-show-in-solution-explorer’.
Is that more what you’re thinking of as opposed to ‘active-tracking’ of the the current document?
Steve – yes the active tracking is too “busy” for me, and the macro solutions are too slow and annoying – so I need a nice, slick add-in! 🙂 I’d like to limit the number of different add-ins I install (due to overlap and sometimes stability problems), so I was hoping there might be a DX plugin (can’t code withtout DXCore/CR/RF installed!)
Steve, did you contact Support Center regarding VB problem? Maybe there is an issue in DX-Core that could be fixed when reported.
That’s actually a great point – good idea and I will do that. If this were ‘fixed’ (e.g., if its actually a bug vs. as-designed) then this tool would begin to work fine under VB.NET too and I could remove the availability logic that says “return false if lang != C#” in the tool.
[…] those of you interested in using my DXCore Refactor_UpdateNamespace plugin (see here and here for more details) but hampered by the fact that prior releases supported only C# and not […]
[…] courtesy binaries of those too so you can get the DXCore 2009.2.4-compatible version of the Refactor_UpdateNamespace plugin […]
[…] Refactor_UpdateNamespace Info […]
[…] 2009.3 Tools Released: CR_ClassCleaner, Refactor_UpdateNamespace, DX_SourceOutliner and More! on Refactor_UpdateNamespace v1.0 Releasedsbohlen on Travelogue: Oredev 2009 Wrap-UpPhil on Travelogue: Oredev 2009 Wrap-UpUnhandled […]