Visual Studio 2005 Refactoring is useless

I'm writing this as I wait for a simple "Extract Method" refactoring to execute in Visual Studio.NET 2005.

I have used other tools in the past that work several orders of magnitude faster, so why can't Microsoft, with all their money and talent, at least approximate the quality and speed of tools like jetBrains Resharper?

Or at the very least, give me a freakin cancel button when it starts thinking, not after it finally starts iterating over files.  That way when I goof and use the Rename refactor, I can cancel and do a manual find/replace (in half the time).

At this point, I'm going to try Scott Guthrie's hack to omit web files from the refactoring and give it one more whirl.  

More generally, this is just one more example demonstrating how common a practice it is for Microsoft to target their first SP to reach Feature Complete in their products rather than RTM.

14 Comments

  • If you use the VS 2005 Web Application Project option, you should find refactoring performance very, very fast. I have a tutorial here on how to convert your existing project to use it if you want to try: http://webproject.scottgu.com/CSharp/Migration2/Migration2.aspx

    There were issues with refactoring perf with Web Site Projects in the RTM release of VS 2005 (hence my article above). A number of perf improvements have been done with refactoring in SP1 to hopefully address these.

    Hope this helps,

    Scott

  • Yes, SP1 significantly speeds up refactoring so that it's actually useful.

  • I use the Web App Projects and I haven't had a speed issue.

    The only thing on the refactor menu that I use is rename; it works, just beware of the replace in strings option.

    I've tried exrtact method a few times, but its never quite what I want so I need to fix it up after.
    The net result is that I can do the refactoring just as fast by hand.

    While VS 2005 RTM is much better than the VS.Net (2002) RTM was, I still get the feeling that things lose key functionality because of ship-dates.

  • Thanks for the info. I was already aware of the Web Application Project, but my current project team is using the default Web Site-based development.

    So, are you basically admitting that the default web-site based development implementation sucks, or is this just a specific workaround for this problem?

  • Scott: that's great, but with the vanilla website projects (thus without a project file), the speed is already dogslow even when you have 2 or 3 pages.

    What's WORSE, is that when you're inside a method in the code behind, and you for example rename a LOCAL variable (so it's only known to the method!), it will scan all pages when you enable refactor renaming.

    That's completely bogus. The intellisense engine knows what the scope is, so why the refactor engine reverts to scanning all pages is beyond me.

    Anyway, when renaming a library method, I simply rename it, recompile and fix the errors manually. That's WAY FASTER than finding any reference in the web pages.

    Same goes for shift-f12 on a method. The feature is completely useless in website projects, even in small projects, so how on earth this could have passed QA is beyond me.

  • Both are good project options to use - and each has pros/cons that the other doesn't have. The one you should pick depends on your particular coding preference.

    I'd recommend reviewing this article that discusses more about the different options and how to optimize the build performance of each: http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx

    Scott

  • if you're using a class library try putting it into a sepeate 'solution folder' from the web site. I think this might help.

  • Yep. I just tested again with a solution I have for a large site I built with built is web site projects. I have the class libraries in one solution folder, the web site in another solution folder. If you refactor the changes only extend to references to inside the solution folder. This is not a perfect solution becasue your pages can possilby break - though you should see that on compile, but it is faster.

  • Frans, you nailed exactly what I was originally trying to convey (albeit a bit more succinctly).

    ScottGu, I have read that article previously, and it did little to improve the refactoring speed.

    Generally speaking, VS.NET is way bloated. There are times when, for productivity's sake, I open my .cs files in a simple(r) text editor like Notepad++. Between build providers, custom tools, and intellisense causing "lag" while coding, it can become quite a productivity killer at times.

    Dont get me wrong, I love the power of VS.NET, I just would like greater productivity.

    Oh, and dont get me started about the new help system...

  • Lynn: My current solution setup is exactly as you describe. I have tried various configurations on 2 different PC's (a P4-3ghz 2gbDDR, and a Core2Duo 1.86ghz 2gbDDR2) with no improvements.

    Looks like I'll have to suffer until SP1 RTM's and pray it has fewer or different bugs.

    ~Lance

  • It would be really good to get a real refactoring toolset in Visual Studio 2005. 7 refactoring tools is for sure not enough.

  • As I said above (and in the article I linked to), if you want lightening fast refactoring you should modify the project to be a Web Application based project.

    The different project systems have different things that they are optimized for. If you want the fastest full-build and refactoring performance, the web application project will give it to you.

    Scott

  • Yeah, I appreciate what you are saying, but its not always a simple thing to change mid-stream during a commercial project.

    My home projects will definitely benefit though - so I appreciate the tip.

  • HI Scott There are various reason why I will not use the Web Application Project(As discussed by yopu in an article). But if you say taht visual studio cannot give me a better refactoring solution in the web site project application, Its very sad.

Comments have been disabled for this content.