views:

46

answers:

2

I'm working in a class library and there are other source projects associated with the same solution. Is there a way for me to stop the VS refactoring tools from traversing those other projects, without removing them from the solution, but keeping everything the same?

The reason I'm asking is because I often know the changed symbol doesn't exist in the other projects and refactoring takes a long time looking through all projects in the solution. Especially if there's an unwieldy Website project in the solution.

A: 

Not using the default refactoring tool, no. You'll need to create a new solution that contains just that one project (which you can do by just opening the proj file directly), execute the rename in that context, and then return to your original multi-project solution.

Dan Story
I was "afraid" of that. I was hoping for a more manageable solution. For example, it would be nice if VS had "refactoring sets" The programmer would add multiple projects of choice to a set, and could choose a set for any initiated refactoring task.
John K
I think it's a pretty unusual need. Typically people are concerned with trying to get all of the references, not trying to *leave* broken references. Even Resharper, which has probably the best refactoring functions of any .NET developer tool, doesn't support that kind of "partial refactor".
Dan Story
Incidentally, since your primary complaint was speed, you should try Resharper. If you enable full-solution parsing, it builds a very comprehensive solution-wide symbol index that lets it do refactoring very quickly, without having to use the full search that the VS Refactor command uses. Downside is that it's a fairly expensive commercial plugin.
Dan Story
A: 

(Ran out of space in a comment, so I'm writing a full answer instead...)

@Dan: I think the underlying need is quite common: we want refactoring (and every other computer operation) to appear instant*. Whenever here is a noticeable delay, we wish for things to be faster, and we start looking for ways to make that happen.

One of the reasons that the built-in refactorings for C# can be slow is that we deliberately chose correctness over performance. We knew that some of our users would be heavy in to TDD, and they would be able to detect and recover from an error in an automated refactoring, but that many users would be at the mercy of our implementation. We figured that if you knew that we might get a refactoring wrong, you'd grow suspicious and stop using the tool. So, we take the time to do detailed validation of the refactoring. (There are other reasons, and it is possible to do fast, reliable refactoring, but shipping is a feature, too.)

In this case @jdk wants to tell Visual Studio "hey, don't worry about these other projects, I'll accept the risk of missing something important". There isn't really a way to do that, I'm afraid.

You didn't say which version of Visual Studio you are using. I'm pretty sure the team has continued to improve the performance of the tools, so you may want to check out the VS 2010 RC (http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx) and see if things are any better.

Some of the 3rd-party refactoring tools out there are faster. I haven't looked closely, but I'm sure that some take the simple approach for performance, and make mistakes in some cases, while others are more reliable. Choose carefully.

*Whenever someone would ask me "is this fast enough?" I asked back "would a user notice a delay?" If yes, then they would like it faster. Any delay is disappointing, just like a missing feature or a bug. Our job is to decide when it's the right time to make more changes and when to ship.

Jay Bazuzi