Some beta 2 feature changes

Some beta 2 feature changes

  • Comments 35

We’ve heard a lot of great feedback from VB developers about the Whidbey product this year, in many different ways. We visited a bunch of cities on our world wide user group tour (; we’ve read blogs and newsgroups; held chats; and gone to conferences, among other things. And of course there’s the product feedback center on MSDN ( Recently we made some changes to a few features that we hear a lot about from developers: refactoring, code snippets, and ClickOnce deployment. I’ll describe those changes here, and as always, we’d like to hear what you think.

One thing you should know—the changes that I’m describing here were made after beta 1, so the first “big” release that you’ll see them in is the Visual Studio beta 2 release, some time early next year. They’ll also show up in a Community Tech Preview release sometime later this year.

The ClickOnce change is that ClickOnce deployment will now be available in Visual Basic Express. VB Express is all about building smart client applications, and ClickOnce is the best way to deploy a client application with Whidbey, so we’re very happy to be able to put the two together.

We removed one code snippet feature, and added another one. In beta 2 you'll be able to assign a shortcut to a snippet and then invoke it from the keyboard.  In the Visual Basic code editor you can type “?” (question mark) and then Tab to bring up the list of all code snippets. If you know the shortcut for a specific snippet you can type that and press Tab to immediately insert the snippet. As in beta 1, you can still right-click in the editor and choose “Insert Snippet…” to get the full menu.  The feature that we had to remove was the integrated snippet editor, because we didn’t have enough time to ensure that it would be at ship quality in time for beta 2. Instead, we’re working on an external snippet editor that will be available around the time that VS ships, so that we’ll still be delivering a good snippet editing experience.

Refactoring is another feature that we've heard a lot about from VB developers. Beta 1 already supports the “rename symbol” refactoring, which allows you to change the definition and uses of a variable (or class, or function, etc) either by right-clicking or with a smart tag. We'll change all occurences of the symbol in your project (or in your solution if you have a multi-project solution). For beta 2, we have made a number of improvements to rename symbol. For instance, when you rename any part of a designable partial class (like a Windows Form or User Control), we’ll rename all of the other parts, even if they are hidden from view. We had hoped to include additional refactoring support for Whidbey, but weren’t able to in the limited time that we had. This is definitely an area that we’ll be working on for future versions. We also expect to see companies providing VS addins that support refactoring in Visual Basic. (There are already at least a couple that work with VB 2003.)

Steven Lees
Visual Basic Program Manager

Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post
  • Phil Wells wrote:
    > Serious developers will defect to C# leaving
    > only the hobbyists programming VB. But
    > perhaps that's been your aim all along?

    That is Microsoft's stated aim:

    "When asked who Microsoft sees as the developer audience for VB, the answers were enlightening. Treadwell characterized developers as coming from two camps, those who would approach the problem of writing a tic-tac-toe game by drawing the UI first (VB developers) and those who would first create the classes and code required for the game logic ("computer science" developers). The interviewees said that Microsoft would make further alterations to VB to help target that entry-level audience."

    So, yes - VB is entry-level, aka hobbyist. That's why I'm now a C# developer rather than a VB developer.

    I actually believe that VB.Net should be more entry-level than it currently is. I believe VB coders should be able to write smaller programs much much faster than C# developers can write them. However, that will inevitably constrain the VB language from doing everything that C# can do and thus prevent it from being used to build larger systems.

    You can see this in the V1 product with the background compile in VB.Net - current large VB.Net products have to stop using the IDE because background compile causes the whole system to slow down to such a point that no development can be done. However, this feature enables smaller programs to be written faster.

    Phil Wells also wrote:
    > Frankly I wish MS would drop VS and let a
    > company such as JetBrains develop it

    Have you seen JetBrains Resharper?
  • I don’t agree with RichB’s comments on VB should be for hobbyists etc. The comment on using VB to build smaller programs is interesting, because, as I see it, as we move towards SOA “programs” will be smaller. Rather that having one large object model in a business application we will tend to have more smaller object models.
  • The Basic line has never and will never be a purely hobbyist family. And degrading VB to some light computer info. tech class language would defeat the purpose of all this CLI stuff we're pushing.

    I'm still lost on why IDE features can be so language specific. I'm still lost on where C# found the magic cycles to get EnC. I'm still lost on why anyone would want those default instances back.

    Back to my disagreeing. Now that C# has "our" Edit&Continue and "our" Forms Editor (If they get a background compiler I'm gonna quit programmer), I don't think it's fair to say that people who start with the UI are VB Developers. Furthermore I, a VB Developer, have written whole class systems and code for game logic of a Chess game and plenty of other programs before thinking about the UI, in VB.

    To me it is, and has always been, even when I was a VB6 developer choosing not to program in C++ (and I could have) an astetic issue. VB and C* are on opposite sides of a spectrum, and to me all those ripoff, C-wanna be, semicolon-terminating, braces-using, case-sensitivity-worshipping clones (Java this means you) are just displeasant to work in. It's not because I'm stupider. My eyes just have things they like to look at for long periods of time at late hours of the night. Take a journalism class or photography, the human eye has all sorts of neat preferences.

    Take a look at the System.Reflection.Assembly Class overview example on MSDN. Code littered with ambiguous symbols bothers me. I enjoy english, End If, and all those other "wordy" things, I think they make my code clearer and cleaner in the same way that I enjoy indenting and using #Regions. I don't see logical differences between my name, Anthony, written in the 128 possible variations of it by case. I also look at a logical line of code as a physical line of code and would sooner pick a period for a line terminator than the semicolon.

    Does this mean I can't use C#, no, I have. Does this mean I'm a "stupid n00b programmer", no, I'm not. Does this means I should be penalized for my visual preference, or worse yet my 7 years experience and comfort in BASIC languages and have to jump around between the 8,000 new "someone thought me up in their basement" languages (Yeah, I admit it, PHP and Python bother me) learning their libraries to do increasingly integrated task? No.

    I'm in .NET for reasons: Power & Flexibility. Multithreading, delegates, Object-Orientation, Web Apps, all wonderful. I would prefer Microsoft to not backtrack into pre.NET days of extreme language disparity, is that so wrong?
  • Hopefully one of the old VB6 features may be back in the beta2: overlapping transparent usercontrols.
  • No more refactoring in VB.NET is a great strategic error. You should think about it, unless your objective is to make VB.NET a second class environment far behind VC#.NET ...

  • Why didn't MS add real VB and C# parser class to .net yet? This will at least allow such features like refactoring to be a part of IDE, not of language. As far as I know code improvement plug-ins (like IntelliJ ReSharper) are made language specific because their authors don't want to write two parsers instead of one. If it was a real parser class for both VB and C# integrated to framework, I think, plug-in authors would be very happy...
  • 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'.

    Give us refactoring, let the developer decide on code snippets or refactoring.

    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...
  • I don't want anybody here leave VB because of the lack of refactoring! We have used VB for 10 years without refactoring and we can wait another year.
  • 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.
  • Why can't the refactoring features be released as an add-in ASAP after the release of VS 2005? MS needs to make a serious effort to promote VB as the enterprise development language that we all know it is. Surely the resources that would be needed for this a comparatively small to the sort of funds Microsoft invests in other areas, can they not see the value for money they would get in developing a refactoring add-in?
Page 2 of 3 (35 items) 123