VB Refactoring

A few weeks ago, I wrote about Edit and Continue support for C# in Visual Studio 2005, in response to overwhelming customer feedback.  Thanks for your wonderful words of support and great feedback.


We’ve also had tremendous feedback on the MSDN Product Feedback center among the VB community asking for Refactoring support.  (If you’re not already familiar with Refactoring, click here for a brief explanation.)  As many of you know from reading the VB Team Blog, the VB team is NOT going to be able to implement Refactoring in Visual Studio 2005.   This is disappointing to all of us and I wanted to talk a little bit about what went into that decision.


The VB team spent a great deal of time investigating how they could add Refactoring to VB 2005 and were very passionate about finding ways to get it done while still delivering on all the other feature commitments that we’ve made.  It was a long, drawn-out, hard discussion internally and has become an emotional issue on the blog after they posted the status.   When the team was trying to plan how to implement this feature, they were also faced with the reality of having a lot of work that needed to be done before we could deliver a great product to you all with quality on the already committed feature set, and refactoring is a large and complex feature.


Was the VB team listening to their customers?  Absolutely.  In the end, I discussed the feature and what it would take to implement with the team and decided that we could not fit it into our plans for VS 2005 without significantly delaying the entire Visual Studio 2005 product release.  This was a hard decision and trade-off that we had to make.  Deciding not to implement a feature that has community support and passionate advocates internally is one of the hardest decisions involved with shipping great software.  Refactoring in VB is on the list of features that we will consider after we get done with Visual Studio 2005.   


VB.NET in Visual Studio 2005 is our best VB ever.  With the return of Edit and Continue, more than 500 Intellisense code snippets, My, AutoCorrect and literally dozens of other VB features, I am confident that developers are going to love it.  We’re making the hard decisions that we need to make in order to get a great Visual Studio 2005 product to you as soon as we can.



Comments (32)

  1. richy_roo says:

    This is really, really sad.

    The refactoring features increases productivity and VB.NET is meant to be a ‘productive tool’. I really think there’s been a mistake here.

    Code Snippets! useful for the ‘hobbyiest’ a term which occurs frequently, but isnt that kinda anti-refactoring – taking prebuilt code, which should really be method calls and copy/pasting them x times through your application.. ‘anti-refactoring’.

    I just think that Code snippets in, Refactoring out, adds weight to the hobbiest tag. That makes me sad.

    After the hype there still the message spreading that c# is the ‘main language’ and now the news that c++ is the future and should be considered in 2005. lets fly the VB flag and get the OO stuff in there..

    C’mon the c# team got edit and contine…

    please, please, please give us refactoring, squeeze it in somehow…

  2. Daniel Moth says:

    For some of us, the syntax of the language is irrelevant when making a choice and we make it based on features. I like to call us professional .NET developers (no language labels).

    >>VB.NET in Visual Studio 2005 is our best VB ever.

    What is it exactly that VB gets with Whidbey? Snippets and My (just code examples, no real value) and a lot of catching up to C#2003 (this was necessary). That’s it! My blog has a lot more on the subject but basically the gap (feature-wise) between the two languages widens. Throw into the argument perf and VB is a lost cause for non-hobbyists devs that don’t care about the syntax.

    Now, to be honest, I understand what you are doing from a business perspective: Driving the professional community to C#; just come out and state it please so we can all stop talking and arguing about it.

    Right now there is only one killer feature when programming in VB: Background compiler (something it always had).

  3. James Snape says:

    I guess the VB developers are understandably going to be a little pi**ed off with the lack of feature. But as you know from past posts, I agree that you have to cut features to make a schedule. It’s always tough, but hey – there’s always the next release.


  4. I can understand that implementing Refactory on VB could be a long work, but I’m terrible disappointed for this lack on the next VB version. Why VB must be always a step under C#?

    However, I’ve a personal question: why spent so long time to implement a feature like MY? I think I’ll use it not too much often and personally I don’t think it could be really useful and revolutionary. All the thing you could do with MY you can easily do NOW. Who has schedule the working table for the VB staff?

    We don’t need toys like MY, we need working tool like Refactoring. 🙁

  5. Frans Bouma says:

    +1 for Daniel Moth’s argument. Just come out and confirm what a lot of professionals already know.

    I also find it hard to believe that refactoring was too much to do. After all, the VB.NET compiler does compiling behind the scenes, it knows EVERY symbol and where it is located. The core issue for all refactoring tools is: where to get the symbol information so refactoring can be done reliable? In VB.NET, the compiler knows this, the code is already analyzed, the results are there, ready to be used.

    I understand the positioning problem Microsoft has and that there are a lot of professional developers using VB.NET, but make up your mind! OR make both languages evenly powerful and let hte user decide on syntax, or make the difference in positioning. What you’re doing now is making VB act like a Visual Bob kind of toolkit which looks like it’s targeted at beginners and hobbyists, alienating professionals.

  6. Aaron Junod says:

    This still hurts when I see threads about it. Personally, I’d rather refactoring then e&c or my, but I guess I’m just 1 professional vb.net developer in a sea of millions. Obviously by the tone of these posts, I’m not the only one though.

    You guys also hit the nail on the head when you state these features are targeted towards hobbyists. I spend much more time refactoring or writing new code then debugging (read unit tests), so to me, refactoring would have been the biggest productivity booster. Oh and I doubt I will touch the my namespace, at least without some in depth analysis of the IL it produces and what its writing for me.

    Now we professional vb.net people will need to bug mgmt to buy us a refactoring product if we want the productivity gains. Not good. I guess I will be stuck wishing we were a c# shop.

  7. Alex Kazovic says:

    I think it is a bigger issue than just refactoring in VB. Whilst I am disappointed it didn’t make it into VS2005, I could live with the decision if I felt that it would be included soon afterwards. Unfortunately, the time between releases seems to be measured in years rather than months. Therefore, for me, the issue is more to do with the development process/cycle. I would like to see releases (or add-ins) for VS more often than the current schedule.

  8. Again about VB.NET Refactoring

  9. Well, I understand that it’s too late to munge the schedule to get this in NOW. I do wish there had been more transparency and discussion of tradeoffs months and months ago, when professional VB .NET developers first got upset about the lack of refactoring. It seems clear that many of the most vocal VB proponents would have voted to dump the My namespace in favor of refactoring, had they been given the choice – though I suspect surveys of the entire VB marketplace might go the other way.

  10. Well, I understand that it’s too late to munge the schedule to get this in NOW. I do wish there had been more transparency and discussion of tradeoffs months and months ago, when professional VB .NET developers first got upset about the lack of refactoring. It seems clear that many of the most vocal VB proponents would have voted to dump the My namespace in favor of refactoring, had they been given the choice – though I suspect surveys of the entire VB marketplace might go the other way.

  11. Darrell Scott says:

    Well, this is the first I’d heard of this announcement, and it quite frankly breaks my heart.

    Refactoring was a key feature I was looking forward to seeing in Whidbey – something that could really improve our productivity and help keep the codebase maintainable. It’s becoming patently obvious that Microsoft’s priorities are with C# instead of VB.Net.

    As a previous poster mentioned, we don’t really care for the syntatical sugar, particularly at the cost of a useful feature such as this.

    I’m beyond disappointed with this decision. We migrated to VB.Net with MS’s promise that it would be fully embraced. That is clearly not happening.

  12. Andy says:

    You must question the sanity of introducing the "My" class and "code snippet" changes as opposed to refactoring. This just reinforces the point that VB will be the hobby language instead of the professional language it should be. A crying shame.

    The VB team needs to be keeping up with the C# team and doing more in order to correct the detrimental feeling about VB in the industry, but sadly, it appears professional features are excluded for changes that bring next to nothing to the party. IMHO it appears a decision was made to tailor VB as a classroom/learner language, and this underlying trend is what is worrying, not just that refactoring was excluded.

  13. Ray says:

    Personally, I don’t care much about the refactoring in VB.Net. I don’t even use in it C#. If you are a good coder, follow proper design guidelines and can envision your solutions properly prior to coding them, refactoring your code is a minimal and often unused process. I would much rather have a background compiler rather than a refactoring tool, and VB provides that. C# programmers complain that VB gets a background compiler and C# is behind VB.net in that respect. The background complier is the biggest reason I use VB over C# in many cases. You guys responding to this post act like people are using C# over VB.Net because of a refactoring tool. How about losing the background compiler and replacing with a refactoring tool? You’ll still complain. Please. You guys are arguing for the sake of arguing. Look at both sides and you’ll see that neither language IDE is better than the other, and both provide unique features that make them productive.

  14. Radi says:

    Ray, these guys are not arguing just for the sake of arguing but because they have a clear concept in mind of what is and is not important to have in VB.NET. I think throwing in the background compiler is kind of distracting from the main discussion here: why did My do it into VS.NET2005 and refactoring didn’t?

    I understand the schedule problem, but I’m very disapointed about this. This was THE reason I was waiting for VS.NET2005. Now I’ll switch to SharpDevelop as soon as their refactoring support has been built in.

  15. Ray says:

    Radi, you help clarify my point. If you only use a particular language and IDE because you need and possibly rely on a refactoring tool to produce good, efficient and maintainable code, all I can say is I’m glad I didn’t hire you.

    From the refactoring link Somasegar supplied: "I’d bet you would agree that a significant part of any engineer’s day is spent re-working existing code to become in some way ‘better.’ In many cases, ‘better code’ is a subjective term, but some common improvements include: adhering to OO-best practices, increasing type safety, improving performance, and increasing code readability and maintainability."

    In my opinion, if you are on my team and you are spending a significant part of your day rewriting and reworking code, you’ll be finding a new job very quickly.

  16. Shital Shah says:

    If you are actively coding, you would probably have an idea how bad this is then it sounds. Its not so much because you dropped it now but its more because it will take again years for you to make another release of VS.Net to get this important feature in. I really don’t understand. Yeah, I know increasing team size doesn’t speed up development but I think there is a way out. You can modularise the process, form an isolated team just for this task or even outsource it to another company or make finer interfaces available for open source development of this feature. I’m sure, after Whidby comes out some 3rd party company would do this in record time and put this feature as an add-in (the way JetBrains did with ReSharper). That would be a shame for your team. These small companies like JetBrains are doing magic with so much limited resources and doing stuff that took Microsoft over half a decade. So why can’t Microsoft put this feature for an auction for any company to do it and put it in release as an unsupported add-on? I’m sure there would be many companies willing to take this as challenge to make it in to your release schedule without bothering your core team. Several professional Java IDEs has refactoring now as a defacto standard. They never seems to have "can’t do it" attitude or complain about difficulties of the resources. Does developing for Microsoft platform means you are always couple of years behind then rest of the world? Its funny that most exclusive developers on Microsoft plateform haven’t even heard the term "refactoring". Is that the effect of staying on the "Dark side"? literally, lol! This is the time I really hate having big giant Microsoft giving out sub-standard products which everyone would be stuck with for few more years to come before they realize that rest of the world is having those features since years. hmm… or am I…?

  17. JavaKid says:

    Well said Shital.

    As far as Ray goes… where do I begin? For starters let’s take a look at this:


    Hopefully this will give you an idea where many of us are coming from. You seem to suggest that if a developer cannot design, architect, and implement software "correctly" the first time… then they should be fired. Well there is a problem with your understanding of Refactoring. One thing that I can accurately predict about large software applications is that the requirements are continuously changing. With these changes to requirements come changes to your code, even when you designed and implemented them according to specification. One way (the best I’ve seen so to date) of handling these frequent changes is to Refactor you code, the concept primarily popularized by Martin Fowlers book:


    Refactoring by the way is a big deal to many of us in the software development community and this is more of an issue about vendors listening to the desires of their customers, and releasing changes to them… not a debate over the most useful feature.

    Oh and I for one would be very afraid to have someone on my team who claims that they don’t need Refactoring tools because their code is so good… come on, really!

    Since we’re on the subject… if you write such solid code Ray, why do you need an incremental compiler holding your hand while you type?

  18. Mike Gale says:

    As a lot of people here say refactoring is key.

    If MS won’t provide it we need some other way to get it in VB.NET.

    CodeSMART, the IntelliJ people… A community approach. (Is the parsed source open enough to make it easier.)

    If there is an update of VB 3 to 6 months after 2005, could VB surpass other languages with refactoring??

    Lets face it, a lot of the automated refactoring is simpler than the refactorings of human programmers. It would be better if this debate were about better refactorings (build your own maybe) than a boolean "something" versus "nothing".

    I’m fairly sure there will be tools in this space. The VB.NET team can help by giving us hooks to do the job better, maybe VB can even surge ahead. (Things like NDoc and MbUnit look like real progress to me.)

  19. Radi says:

    Ray, you talk as if you were in charge of a development team. But very obviously you either (1) are trying to calm down all the disappointed people here (like: "hey, be glad you have a text editor in vs.net, what would you do without a text editor?"), or (2) you have no clue what "your team" _really_ are doing all day.

    So, either (1) you don’t like hear the truth, or (2) your team wastes a lot of time hiding their work from you. Both will cut your productivity and can result in severe problems. You don’t have to listen, but at least think about it.

    (And: get on and read a bit about what’s going on in the world of development. Won’t do you any harm.)

  20. Ray, so do you think Martin Fowler is an idiot? If you go to http://www.refactoring.com, I’ll bet you find many, many things that you/your team doesn’t conform to.

    I, for one, would like to have seen the refactoring tool make it into the VB.Net IDE this time around, but I suppose we’ll be waiting on a third party tool as an add-in to do that for us. Perhaps after seeing resharper, this is what Microsoft had planned all along, just let someone else do the work. I suppose rightly so. Chances are, whether or not MS put a refactoring tool into the VB IDE, some company out there is working on one right now anyways. Either way, I think we’ll end up with a useful tool in the near future. Knock on wood.

  21. I said that I might find something interesting to blog about during my trip to Florida. Well, I didn’t…

  22. I blogged the other day about the top customer issues that we have fixed based on customer feedback via…

  23. Plozher says:

    Try to look here and may be you find what do you want:,

  24. Shelley-bn says:

    <a href= http://index10.setomm.com >latinas</a> <a href= http://index7.setomm.com >reading first classroom</a> <a href= http://index5.setomm.com >mountain meadows massacre</a> <a href= http://index6.setomm.com >sz gallerie</a> <a href= http://index8.setomm.com >robin thicke wanna love you girl lyrics</a>

Skip to main content