@Valdimar:

Thanks for the feedback — that WOULD be a great feature and would make the behavior of this plugin more like the the Developer Express-provided ‘Rename’ refactoring but applied to the ENTIRE namespace value.

Right now the Developer Express ‘Rename’ refactoring only lets you use it to rename the last ‘component’ of a namespace. For example, you can use the Rename refactoring to rename the ‘Folder3’ node in the following declarations…

namespace MyMvcProject.Folder1.Folder2.Folder3
{
…
}

…but you cannot apply the Rename refactoring to the entirety of the dotted namespace path at once, which is really more what you are suggesting here.

Either way, I *will* look into this capability but I think its actually more complex than you might think since I would have to actually search NOT just for ANY ‘using’ statements that reference the ‘old’ namespace but for ONLY those such statements where the ONLY classes in the target files to change are the classes in the file being changed, else this refactoring could easily introduce inadvertent breaking changes.

As an exmaple, consider this…

file class1.cs:
namespace ns1
{
public class Class1 {}
}

—

file class2.cs:
namespace ns1
{
public class Class2 {}
}

—

file SomeParent.cs:

using System;
using ns1;

namespace Parent
{
public class SomeParent
{
public SomeParentClass()
{
var a = new Class1();
var b = new Class2();
}
}
}

—

In the above collection of files, if you were to perform the ‘update namespace to default’ refactoring on the Class1 class in Class1.cs AND replace all references to ‘using’ statements, etc. in all other places in the solution, then the result would be that suddenly the code in SomeParent.cs would stop compiling (since all of a sudden Class2’s namespace would no longer be properly imported into the SomeParent.cs file and Class2 would become an ‘unknown type’ to the compiler).

The only way I could see to accomplish what you’re suggesting (which actually IS a very valuable suggestion BTW) would be to…

1) carefully interrogate ALL of the types in the file whose namespace you are ‘updating’

2) search the entire solution for all instances of those types (e.g., NOT search for namespaces, but search for TYPES in that namespace used elsewhere)

3) if you find one of these types in use elsewhere, check all other TYPES in use in the same file to see if there are any other types in the same namespace but NOT also in the source file with the namespace being updated

4) if there are other types in the same ‘source’ namespace, ADD the ‘target’ new namespace to the ‘using’ block

5) if there aren’t other types in the same ‘source’ namespace, REPLACE the existing ‘using’ statement with one that makes use of the new namespace

This is all ENTIRELY achievable using the DXCore/CodeRush API, but this is just an example to indicate that its probably non-trivial to implement this functionality. And it gets worse when you also realize that its NOT just ‘using’ statements that have to be updated but also explicit in-line fully-qualified references to the namespaces (e.g., var x = new ns.Class1(); statements) that would have to be searched for and resolved as well.

So….this is a long way of saying both “nice (and powerful) suggestion, but a lot more complex than I’m probably going to try to implement any time soon for all of the above reasons” but I *will* accept a patch from anyone wanting to take a stab at adding this really powerful capability to the plugin 🙂

Thanks for the suggestion, I *will* consider it for the future, but its non-trivial so probably won’t be happening anytime soon.

-Steve B.

@Przemyslaw:

I think (in general) your 1-2-3 step is indeed the right process outline overall. I might quibble a bit with the invocation of the optimize-usings refactoring only because it would tend to violate the law-of-least-surprise for the user since performing that action is somewhat tangential to the act of changing a namespace declaration in one source file.

I agree that its pretty straightforward, just not trivial to implement:) There’s a ton of complexity buried in edge cases in even just that outline of yours, but I agree that’s more or less how it would need to work.

As for posting it to the dxcorecommunityplugins site, that’s my intent as soon as I get a minute or two to get in touch with Rory Becker and coordinate my getting access to that SVN repository.

After that, I’d be GLAD to consider a patch from anyone that wants to take a stab at implementing this suggested functionality — its easy to see how it would be valuable, but its also easy to see how its non-trivial to get all the edge cases right 🙂

Thanks again,

-Steve B.