Slow Chat with the MS Visual Basic Team

Friday Aug 8th 2008 by Bradley Jones

VBForums had a Slow Chat with some of the members of the Microsoft Visual Basic team. Find out what's new and important with VB here.

VBForums had a Slow Chat with some of the members of the Microsoft Visual Basic team. You can find the exact questions and answers on the VBForums site at:

In this brief article, we condensed some of the questions and provided the answers that members of the VB team provided. I've also added my thoughts to a few of the answers as well.

Question: (original question by EntityX)

Visual Basic is no longer available as a standalone product. If someone only wants Visual Basic, why do they need to buy Visual Studio? Shouldn't it be cheaper to buy just Visual Basic?

MS Response: (PaulYuk_MS)

Thanks for your feedback on pricing. I agree there may be some good options in a sweet spot price range.

Yes, VB Express 2008 is a very good deal at Free. You can build some serious applications with it; however, you'll want to upgrade to at least VS Standard to get client/server development and client + Web in the same box. There is also a Visual Web Developer Express product that allows Web development in VB and C#.

There is no longer a VB2008 Standard standalone product. There is only VS2008 Standard and above. VS2008 Standard is a lot of product at a modest price at $199 for upgrade or $299 for full retail. All pricing details are here:

Brad's response:

The original poster of this question asked if Microsoft could charge a smaller amount (just a portion of the Visual Studio price) for just Visual Basic. The idea was that if only one language was used, charge only a third the price of Visual Studio for this language.

While this logic seems to make sense, if you dig into what is in the Visual Studio box versus what would be in a Visual Basic box, you quickly can realize that the proportion of Visual Studio that applies to Visual Basic (the value) is not a third. Most of what you use when doing .NET Programming is the .NET Framework. The tools for doing the .NET Framework are virtually the same between languages like C# and Visual Basic. As such, there are not two copies in the Visual Studio box, but one copy. When you filter things down to what is redundant, it ends up being a bit of syntax and some help files. The real value is in the tools and designers.

Bottom line is that if you bought only Visual Basic, I believe it would end up being more like at 80 to 90 percent of the cost of Visual Studio. At that minimal difference, you might as well buy the whole thing! I image that if Microsoft were also to factor in the additional cost of producing a separate product box and such, then the cost might actually go up to matching or exceeding the Visual Studio product due to economies of scale.

Question: (original question by birthjay)

Visual Studio and .NET seems to be getting new editions in short periods of time. How do you expect people to keep up with migrating products every time there is a new release? Where does it end, or when will we see a stable version with only minor changes? There are rumors that companies not going to .NET because of the major changes from version to version.

MS Response: (PaulYuk_MS)

I definitely hear your point that change needs to be gradual & incremental. It isn't cost effective to keep rewriting code to get back to functional equivalence.

From VB6 to .NET, I agree that Interop Forms Toolkit is a great example where you can prioritize where you want modern features, create those new features, and drop them back into your existing code. The idea is to "embrace and extend" the app so you don't need to do a forklift style migration.

The changes between 02', '03, '05, and '08 are much smaller in scale than VB6 to .NET. Each version, we add a few major platform innovations (generics, My, LINQ)—and they were built to work with existing code. You can simply opt in or out of them every release. I would not recommend rewriting code to use them unless you have business need.

Also, we added multi-targeting support in '08 (in other words, you can now use the new tool to target .NET 2.0, 3.0, 3.5, and future). The great thing here is you can upgrade your VS version to get tooling benefits (faster performance, better intellisense, better lifecycle tools) without having to upgrade to the new version of .NET. You can also buy into a particular version of VS (let's say '08) and be happy running on it for a while. You have the choice to upgrade developer-by-developer or project-by-project.

Brad's response:

I see the "upgrade' issue on VBForums more than I see it on other sites that I oversee. I often respond with the question of "If you wrote code last year for the company you work for, why do you need to write more code this year? Things change. Developers need to change. The technical world evolves.

In the mid 90s, I wrote a book on creating an application with a user interface, called Teach Yourself Advanced C in 21 Days. I believe that it was a great book for learning how to capture user input, how to create colored text on the screen, how to interact with data, and more. Using what was in that book, you could create an interface that let you capture information from your users. Of course, you are going to write hundreds of lines of code for what can be done today by simply dragging and dropping an item in the Visual Studio Editor.

Yes, there is a learning curve and a migration requirement if you choose to use newer versions of tools. If you are creating modern software, there is a good chance that the payback in productivity and fewer lines of code to maintain will offset the cost.

Microsoft could upgrade Visual Studio less often to make fewer migrations for people. Of course, that means that if there is a new feature being built that would make you more productive, you are also going to wait longer for that feature to be delivered. In many cases, there is no good answer to whether new editions or too frequent or not fast enough.

The bottom line is that if new features or change were not added that improve on what you are doing, don't upgrade. I find that, with Visual Studio, I am usually waiting for the releases to come. Of course, with Office, I was happy with the 2000 version.

Question (originally posted by szlamany)

We produced our first app for Pocket PCs using VS 2005 earlier this year.

I was wondering what new functionality/device support or compact framework features might be coming with the release of VS 2008?

MS Response: (PaulYuk_MS)

There is a good blog post from the mobile team on significant additions to mobile development in '08:

One of the coolest mobile-specific features is the latest emulator support. It can simulate common and problematic scenarios (battery life changing) and allow you to code/test for it.

Of course, mobile developers get to enjoy most of the big ticket improvements to '08 and .NET 3.5.—VB users get enhanced IntelliSense in many more situations and they get significant enhances to build performance and IDE responsiveness. LINQ and WCF are big-ticket platform features—VB developers get full access to those features inside of mobile.

Brad's response:

I did a video showing how simple Pocket PC development is with Visual Studio. You can find it at:

Even if you don't think you will ever do mobile development, it is worth creating a little application in Visual Studio to see how simple it is. You can use the emulators, so you don't even need a mobile device. Try it!

Question: (Originally question by jmcilhinney)

A great many people still use VB Runtime functions in their code—functions like MsgBox and InStr that have been ported over from VB6. A great many of these are completely useless in that they simply reproduce functionality that is provided asis or more easily in the Framework. There are those that do add some value in some cases, but most would not be missed in terms of functionality at least.

It's my opinion that these functions were probably included in VB.NET to make the legions of disgruntled VB6 developers feel more comfortable when making the switch. It's also my opinion that the vast majority of people who use these functions are either ex-VB6ers themselves or have learned from one.

I always recommend to people to avoid such functions unless they genuinely add value. MsgBox is a prime example of a function that I think should never be used. Many others who recommend not using them cite the fact that they may be deprecated in a future version as one of the reasons.

What is the VB team's position (official, or personal if you care to give it) on using the older VB 6 functions in .NET programs (Such as MsgBox and InStr), and is there any likelihood that they will be dropped from the Framework at any point in the foreseeable future?

MS Response: (funkyonex)

Here's a good paper to read about this topic:

It contains recommendations on when to use the Microsoft Visual Basic functions. Be careful making a blanket statement about always using the .NET Framework classes directly. For instance, the conversion operators (CInt, CStr, CLng, and so forth) are true operators that compile down to IL instructions whereas the System.Convert functions are still just functions. This means you'll get significantly worse performance by calling Convert.ToInt32 instead of using CInt(). There's a post that explains this from Paul Vick at

Question: (Originally by techgnome)

As I understand it, Lambda Expressions were added to provide functionality for LINQ. My questions are as follows:

  1. What the heck is it?
  2. What would I use it for? Bonus points for explaining why I would and/or not use it in some circumstances. Or better, a situation in which I could use it, but shouldn't.
  3. Could you provide an example of one? This is where I've had problems; most of the examples I've seen have been so esoteric, that I just don't get it.

MS Response: (funkyonex)

Hi technome,

I actually had trouble learning them as well and am very thankful that Visual Basic provides the common ones you use in LINQ queries as query expressions instead. So, I think I'll go for the "bonus points"...

Here's an example of a simple Lambda Expression, or as I like to call them, inline functions, that adds x to itself:

Dim myFunc = Function(x) x + x

To call this, we could write:


Which results in: 4

Extension Methods are another new feature and allow you to create methods that extend any type. For instance, you could create your own Print method on the string class. The LINQ framework relies heavily on Lambda expressions as well as Extension Methods. In fact, the LINQ syntax we see in Visual Basic is really just abstracting away Extension Methods and Lambda Expressions for us in most cases. For instance, the Sum extension method accepts a Lambda Expression as one of its parameters. Say we want to sum only even numbers in an array. We can do this in one line of code using a Lambda Expression:

Dim x As Integer() = {1, 2, 3, 4, 5, 6}
Dim sumofEvens = x.Sum(Function(y) If(y Mod 2 = 0, y, 0))

Lambda functions start to get really useful (and necessary) when we start writing LINQ queries. Say we want to Sum all of the products in our products collection by multiplying the UnitPrice by the UnitsInStock. We could write this:

Dim total = (From Product In db.Products) _
   .Sum(Function(p As Product) p.UnitPrice * p.UnitsInStock)

But why? (I think this is my bonus point) In Visual Basic, we don't have to write Lambda Expressions to do aggregate operations like this. (See here: We can instead write this using Visual Basic's Query Expressions:

Dim total = Aggregate Product In db.Products _
   Into Sum(Product.UnitPrice * Product.UnitsInStock)

I love it! Much easier to figure out what's going on, IMHO. I hope that helps clear it up.

Have Fun!

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved