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 (http://msdn.microsoft.com/vbasic/worldtour); 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 (http://msdn.microsoft.com/feedback). 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 1 and 3 and type the answer here:
  • Post
  • Am I reading this OK? There will be no new refactorings offered other than "rename symbol" in VS2005 for VB?? That will be bad news.
  • What about default instances?
  • I'm working on a response to that request...
  • Re: Daniel's comment, yes that's correct. We'll have rename symbol, but there won't be other refactorings in the product. There are already at least a couple of addins that add refactoring to VB 2003, and we're talking to a couple of companies that are working on addins for VB 2005, so the capability will be available. And of course, we'll definitely be adding more refactorings to the next version.
  • Just to be clear, by "next version" I meant the one after Whidbey.
  • Thanks for confirming my fears. The 3rd party approach doesn't fly with me. If it did, I would not be excited about unit testing in TeamSystem or the Class Designer and other VS2005 technologies; a lot of the new functionality is already on offer by 3rd parties but in the end we all prefer to receive it from MSFT (for what I hope are obvious reasons so I will not go through them here). Personally, I use both environments and it is disappointing that the more the languages diverge, the more I have to retrain myself when I switch between them. The C# team managed to satisfy their customer's number 1 request (EnC) so I guess I was hoping that the VB team would follow suit. Looking forward to reading your comment about the 2nd most asked VB feature: removal of default Form instances.
  • I presume that the refactoring is in the IDE rather than a part of the laguage. If that is the case, could you release a new version of VS, say six months after the RTM of VS 2005 that had full refactoring etc.?
  • You're comparing apples and oranges a little bit. Regardless of where the implementation lives (IDE vs language), we definitely expect to include this in the next release after VS 2005, whenever that is. But we tend to go longer than 6 months between releases.
  • I think it’s important to distinguish between .Net itself (in this case .Net 2.0) and the IDE (VS 2005). I think it would cause problems if .Net was updated as regularly as every six months, but that would not be the case with the IDE. You don’t have to have a new version of .Net to update the IDE.
  • VB won't get more Refactoring and a more convenient intelisence as C#, but in the same time C# can get a very complex feature EnC. Why? There must be another important and exciting feature in VB we have ignored while we are looking for something like Refactoring. Who can confirm it for me? :)
  • BOOOO, BOOOOO.... We don't depend on third parties for features we want built into VS from MS. That is such a bad excuse. Next your going to tell us that MS is dropping VS because a third party made something just like it.

    Should have skipped the ClickOnce from VB Express and spent more time on refactoring.

    I too find it interesting that C# developers are getting what they want, but we are getting less than desired features that we want. Does that mean that we are going to turn into C# want-to-bes? :)

    I guess there is always the "Power Toys" option after the VS 2005 release.
  • MS needs to get with the program. Refactoring tools have been around in Java since *2001*. If it's another 2 years before the next VB.NET release, this will put the VB IDE *6 years* behind best practice in this area. Given this, how you can ever expect VB to be taken seriously as a programming language beats me.

    MS should also do some reading on the development technique called 'Continuous integration'. It should not be necessary for VS users to wait years between releases. Set up a continuous integration system and let's get nightly builds of the IDE. If the Eclipse and IntelliJ Idea teams can do it, why can't you? You can't expect your users to patiently wait 2 more years for proper refactoring support in VB. Serious developers will defect to C# leaving only the hobbyists programming VB. But perhaps that's been your aim all along?
  • PS - Frankly I wish MS would drop VS and let a company such as JetBrains develop it. To see why, I encourage you to spend an hour with their 'Idea' IDE if you haven't already. Even if you don't know Java you'll immediately notice a multitude of small but incredibly useful features that that IDE offers that makes it any programmer's wet dream. In comparison, VS.NET is stodgy and awkward.
Page 1 of 3 (35 items) 123