Yesterday I announced the release of v1.0 of the DXCore plugin as described in this post. Almost immediately upon its release, someone pointed out a pretty embarrassing bug that I had apparently failed to test for: the plugin only replaced the portion of the existing namespace string that fell between pairs of periods (“.”) rather than the entire namespace declaration as had been intended. See this comment (and my response) for more details.
Oops 🙁 How embarrassing for me not to have caught that, but my (admittedly minimal) test-case consisted only of a class with a namespace that consisted of just one word rather than the much more common PartOne.PartTwo.PartThree kind of approach that most people use for namespaces in projects. Sure enough, the CodeRush.Selection.SelectWord() method that I was calling does indeed ‘respect’ the use of a ‘period’ (“.”) as a ‘word-delimiter’ rather than only using whitespace to parse ‘word boundaries’ so my overall implementation contained a giant flaw in that it relied on a method that didn’t do what I needed.
In fairness to Developer Express, their behavior for the CodeRush.Selection.SelectWord() method is actually much more ‘appropriate’ in its implementation anyway: more often than not, as a developer you want to select just the part of a so-called dotted-reference between the dots rather than the entire ‘whitespace-bounded string’ all at once.
And in fairness to me, this is yet another instance of why I am continually disappointed at Developer Express’ near-complete lack of documentation around the DXCore/Refactor!Pro/CodeRush API…a simple entry in some API reference could have easily told me that this was the expected behavior of the damned method and saved me both some time and some public embarrassment.
Another Great Suggestion
Proving that more heads are near-always better than one when it comes to evolving features for your products/projects, I also pretty quickly received this comment from an early adopter asking if it would be possible to have the plugin ‘respect’ the inclusion of solution folders in the namespaces it generates.
In its initial implementation, the plugin merely replaced whatever namespace you had with whatever the project default was set to (in Project Properties). But the way Visual Studio auto-assigns namespaces to new class files is by appending the names of each solution folder beneath the project level to the project’s default namespace setting. You can see this Visual Studio behavior clearly if you have an ASP.NET MVC project with a default project namespace set to MyMvcProject. When you create a class in the root of that project, Visual Studio will assign it the MyMvcProject namespace. But if you then add a class to the Controllers folder, Visual Studio will assign it the namespace MyMvcProject.Controllers, appending the name of the folder to the project’s default namespace.
And this pattern continues no matter how deep you make your solution folders. For example the path /Folder1/Folder2/Folder3 would result in the MyMvcProject.Folder1.Folder2.Folder3 namespace being assigned to any classes in the Folder3 solution folder in this case. Thanks to a quick modification, the Refactor_UpdateNamespace plugin has now been changed to behave this way also, properly inserting the full names of each solution folder into the namespace as it fixes them. Thanks for the great suggestion~!
More good news is that I also have a report from a CodeRushXpress user that the plugin seems to work fine (well, as fine as it could with the bug in it!) under the freeware CodeRushXpress toolset so it would appear that you do NOT need the commercial CodeRush or Refactor! Pro products to make use of this plugin.
The updated binary of the plugin is available for download here. As before, if anyone has any comments, feedback, bug-reports, or ideas how to improve this thing, please post a comment here on my blog for the time being until I can get this project moved out to a more appropriate hosting location for it.