Refactoring support in VB.NET

Anand and Tom ask whether VB.NET is going to have refactoring support in Whidbey. The short answer is, despite what the PDC lab person told Tom, “yes.” However, the long answer is, well, a bit longer than that.

What C# is calling “refactoring” is actually a collection of related-but-separate code manipulation features in the IDE. Things that are included under this rubric are, I believe:

  • Symbolic rename
  • Extract method
  • Extract interface
  • Encapsulate field
  • Reorder parameters
  • Remove parameter
  • Add parameter
  • Promote local to parameter

Some of these features are already slated to be included in the VB.NET Whidbey release, such as symbolic rename, and for others we’re open customer feedback as to which ones above they think are important. Or if there are ones you don’t see there, we want to hear about them as well! If you leave comments on this entry, I’ll make sure they get forwarded to Jay, the PM in charge of this area. (The more specific you are, the better. “Do everything that C# is doing.” is helpful, but “Reorder parameters is the most important to me because blah, blah, blah.” helps us even more!)

One thing that is likely, however, is that VB.NET won’t be using the term “refactoring” in the IDE to refer to these features. While that term is fairly common in some quarters, we believe there are lots of VB programmers who are likely to see a menu item called “Refactor” and just ignore it because they don’t know what the term means. We’d like to surface the features more directly so that they don’t get missed by our users. (If you disagree, feel free to give us a holler on that too!)

89 thoughts on “Refactoring support in VB.NET

  1. BooGhost

    Jeezus, when will the MS Gods quit trating VB developers like redheaded step children? Despite what the intention was, VB.NET is NOT and never will be VB. It may share syntactical similarities, but VB.NET is an entirely new beast. The Whidbey release will be adding generics and operator overloading (amongst other enhancements). Do you think a developer, steeped only in VB, knows that those jewels are? Of course not, VB has never had those. Before I start rambling I’ll make my point and be done with it. Quit treating VB developers like the missing link. Call refactoring what it is. Add as much and as many enhancements as you possibly can to the language.

  2. dave pinch

    two yer ago I couldnt spel programmar, now I are one! Visualbasic is a gud language. do not spoil language with words from snobbish c # programmars, who think they know every thing. i have written calarie counter application. i know whta I talking about.

  3. Edneeis

    I just wanted to add my 2 cents and say that I think Refactoring is an extremely useful tool and should be included in VB.NET and with the name ‘Refactoring’. I think the name should stay common among the different languages especially for those that switch back and forth between C# and VB.NET. Also to destroy the sterotype that VB.NET programmers need everything dumbed down.

  4. Denis Giacomelli

    I suggest to make Refactoring as similar as possible to C#. I tried it in Whidbey (PDC build) and it is very useful. Do not change any word; I’m VB.NET developer (become from VB6) and I do understand what Refactoring is, what generics are and so on. If any VB.NET developer doesn’t he or she won’t use it.
    Beleve me, that if you will change naming from that in C# it will be confusing for many developers. And for every menu command C# and VB.NET developers must read some articles to understand.
    I agree with Roy Osherove.
    Summary is very easy: use the same refactoring features in VB.NET as those in C#; I beleve your code for this feature is generic enough (design patterns) to simply implement it in VB.NET.


    Denis Giacomelli

  5. Pingback: Walt Ritscher: Thinking about co

  6. Amr Essam

    I develop with both C# and VB.NET, but I like VB.NET to be better because I am old VB developer.

    I just installed VS.NET 2005 (Technology Preview), and this my prompt feedback


    I surprised that I found productive feature in C# and not

    in VB.NET, this features:

    1) Refactoring

    I tried Refactoring in C#, It is really very productive


    2) IntelliSense/Auto Completion (Keywords)

    Now only in C# debugger feel the Language keywords like

    (private, public, foreach …), and auto complete it to


    However VB.NET have longer Keywords such as (MustInherit,



    I dreamt that I can find these features in VS.NET, but

    unfortunately I frustrated when I found this feature in C#

    not VB.NET 🙁

    Microsoft always say that it concentrate on Productivity

    features in VB.NET, How does VB.NET 2005 lack these

    very productive features ?!

    Looking forward for your reply.

    Amr Essam

    Consultant & Team Lead


    Dallas, Texas

  7. Pingback: Stefan Demetz

  8. Jerry

    Why even have text on the menu at all? I think most VB programmers would prefer a cute little icon.

    In fact, clicking the icon should play a video clip of that monkey who throws poop — most VB developers I know would clap & giggle for hours…

  9. Anthony D. Green

    A lot of the above mentioned C# Refactor features are important, in fact I see no reason not to include them all and then some.

    Symbolic rename (Must have)

    Extract method (Useful)

    Inline method (Not as useful and harder to manage)

    Extract interface (If this means derive an interface from a class’s default interface then it sounds neet)

    Encapsulate field (Assuming this deals with the who private field public property discipline I live with, Must Have)

    (sure, why not) {

    Reorder parameters

    Remove parameter

    Add parameter

    Promote local to parameter


    wrapping sections of code in black contructs would be great since the IDE starts reindenting and bitching when I start a Do or an If or a Try.

    I could enjoy transforming select cases and chain elseifs back and foward but it’s not on the top of my list.

    Something great would be a shortcut for exposing methods through composition, of course at this point we’re crossing a line between refactoring, reformatting, macros and shortcutting all the more reason that an alternate term to Refactoring would be just as applicable.

    On to the higher holier issues. I think it’s clear from the last 50 posts that VB coders have certain… feelings about how the programming community percieves them, I share this psychological complex and have often made violent threats against my C++ coder friends on it. VB coders are not stupid, second rate, or amatuer we just want to enjoy our work without all the "hard core" masocism of other languages. I didn’t know what refactoring was so I looked it up. You could call it refactoring and be fine, just document it, put it in all those cute "What’s New in Visual Basic .NET 2005" articles and they’ll get it really quickly. We had classes in VB6 they were just very limited, when the time for VB7 (.Net) came they (MSDN) told me what it was.

    Despite popular opinion the concept of inheritance is far from complicated, and VB6 coder worth their salt could assimilate it in short time. We’ve accustomed to our language getting updates (unlike the 20 year old C++). It’s just a matter of when and why to use the new features, and that comes with experience. As for VB7 not being VB6 – that’s crap. Microsoft BASIC languages are notorious for being easy to upgrade. Read a manual on the first BASIC, Quick Basic, and VB4. those jumps aren’t far to begin with, but VB6-VB7 is certainly not a grandcanyon leap. VB7 is to VB6 as C++ is to C (note the +1 version number).

    However if you call it something else that’s intuitive that’s just as well. We pride ourselves on clarity and productivity – that’s why we use Event and AddHandler intelligently (and implicitly) instead of the mangled BS that C# does explicitly. We know how events work great, doesn’t mean we want to see it. That’s why we were passing arguments ByRef when C/C++ coders were still in their caves passing pointers around and dereferencing them constantly and that’s why we were dragging, dropping, and resizing in our designer when C/C++ style coders were managing HRESULTS and what not. So calling it "Change to" or "Wrap in" or "Replace with" or "Transform into" would be fine and dandy, whatever gets the job done.

    I agree that .Net languages should have a high degree of consistency in ability and terminology. That is something I love about .NET, despite the occasional unsupported features (though they are disappearing with operator overloading and unsigned types!) the libraries and the concepts are language neutral. However if VB.NET wants to say NotInheritable instead of sealed, MustInherit instead of virtual or abstract or whatever, Default instead of however the hell C# does it, and use human readable common english words instead of obscure comp sci references, then what the hell, why not.

  10. Brian

    It isn’t bad enough that C# programmers think VB programmers are stupid (even though many programmers switch between the two languages as required), but what I hate is to hear that the MS people designing VB.NET think we’re stupid too. Can we get someone on the VB.NET development team who actually respects the people that are using the tools they write? This is a disgrace.

    I have an idea, let’s "dumb down" all the words just for VB programmers. That way, when a C# programmer talks to a VB programmer, neither one will know what the other is talking about. The C# programmer can continue to live under the illusion that VB programmers are too stupid to know what "Refactor" means. Let’s also change all the words relating to OOP. God knows we could never understand that. Don’t leave out databases. In fact, create the ADO.STUPID classes just for VB programmers so that everyone can act like they don’t know how to do database design either.

    And don’t get me started on people who brag that they are C++ programmers but when you look at their code its just C with a better different compiler.

    What a shock it would be to think that this VB programmer went to graduate school and has a successful consulting business for Fortune 500 companies.

    You people need to get out of your cubicles and spend a little time working with real programmers. You’ll find out that the language doesn’t mean anything. It’s the programmer writing the code.

  11. Pingback: An agglomeration of my thoughts

  12. Pingback: Ian Blackburn's Weblog

  13. Pingback: Ian Blackburn's Weblog

  14. Pingback: Panopticon Central

  15. Pingback: Barely Legal Substance

  16. Glenn

    This discussion would not even be here, if VB.Net developers didn’t know about refactoring. I don’t see reason to call anything else. To call it anything else other then refactoring will make it more confusing espessially to people who use VB.Net and C# interchangibly. Since it is a new feature it would need to be explained to people who have no idea what it is no matter what you call it.

  17. Jim

    Refactoring is the term everybody uses. If you give it a non-standard name, it will just confuse VB.NET developers.

  18. Pingback: Programando .NET

  19. Michael Earls

    The word "refactor" is not a C# term. It is a software engineering term. If a VB programmer is confused by that word, I’d argue it’s time to hit Google and learn a thing or two about the profession that they’ve accidently stumbled into. Deep breath. 😉

  20. VB programmer

    Everyone keeps talking about "refactoring". What is that?

    Also, what does .NET stand for?

    –a VB programmer

    just kidding

  21. Chris McKenzie

    I started my career as a VB5/6 Programmer. When I saw the advance press for VB .NET I was so stoked because I had been butting up against the limitations of VB6 for a long time. I couldn’t wait to get my hands on the more powerful tools.

    The power of VB development, IMO, is not in being a dumbed-down language–it’s in the verbosity of the language syntax. One can READ VB out loud, and it almost makes sense as english language. This idea that VB developers are technically stupid is incorrect. Let’s stop driving an artificial rift between VB developers and developers of other kinds. Please use industry standard language to describe features.

  22. srinivas Nuthigattu

    Hi All,

    I am not a programmer. I am a student who needs urgent help. I have some data where i have to send emails to my batchmates and their friends every day to request some information. my requirements are as follows.

    i have created hyperlinks for the email id’s in excel i have a seperate column which has some data. all i want to do is when i click on the hyperlink a new mail is automaticall opened. now i need to some how put the cell info in the subject line. can some one please help me ???????????

    My email id is :

    Thanks and Regards,

    Srinivas N

  23. the blob

    Why are you posting your homework on a thread about Refactoring!

    Homework is a learning experience not an excuse to skive.

  24. Pingback: Living .NET...

  25. Alan

    "One thing that is likely, however, is that VB.NET won’t be using the term “refactoring” in the IDE to refer to these features. While that term is fairly common in some quarters, we believe there are lots of VB programmers who are likely to see a menu item called “Refactor” and just ignore it because they don’t know what the term means. We’d like to surface the features more directly so that they don’t get missed by our users. (If you disagree, feel free to give us a holler on that too!)"

    See, this kind of attitude is the problem w/VB.NET. You should make it *exactly* like C#!!! What is the problem here????? Why do you people insist on rolling programmers into a separate category? I’ve done java for 4 years, and prefer c#, but ONLY BECAUSE YOU FOOLS WHO PUT WORDS INTO PROGRAMMERS MOUTHS INSIST ON CRIPPLING VB.NET! Get w/the program.

    This isn’t rocket science–just give the same features as c#, including volatile variables, etc.. And add optional parameters to c#. See how easy that is? Duh.

  26. Pingback: Panopticon Central

  27. Tony

    I find this misguided MS view of VB developers very insulting. It can largely be blamed for the fiasco that was suppose to encourage/help VB6 developers into VB.Net

    I have many, many years experience in software engineering — probably more than most in your .Net team. This involving multiple languages; in fact, language design, O/S development, & massive databases.

    Through a turn of fate, I’ve recently found myself developing in VB6 (which I actually quite like for rapid development). However, this is "Enterprise development", incl. multi-threading, shared memory, multi-tier servers, Windows Services, etc., etc.

    …just where does that fit into the myopic view of VB usage that requires a Janet-and-John UI?

  28. Pingback: Anonymous

  29. Pingback: Anonymous

Leave a Reply

Your email address will not be published. Required fields are marked *