Visual Studio 2010 SP1 Beta released: Great news for VB developers

Today, Thursday, December 9, Microsoft is releasing the beta version of the Visual Studio 2010 Service Pack 1 to the public, MSDN subscribers have had it for a couple of days now. It has a Go Live license, so even though it is a beta release you can use it in your products today. Apart from many tweaks and bug fixes it also contains several cool new stuff:

• Intellitrace for 64-bit and Sharepoint.
• Silverlight 4 tools.
• Local help viewer.
• Performance Wizard for Silverlight.
• Unit testing on applications targeting the .Net 3.5 Framework.

All of the above features are great and you can read more about those plus many of the bug fixes and also find links to the downloads on Brian Harry’s blog. However in this post I’m going to spend some time on one particular new feature that, I think, will bring great joy to all VB developers around the world. It is also a big step towards the goal Microsoft has put up to bring language parity between the VB and C# languages. This new feature is simply called: VB Compiler runtime switch.

History Lesson

Visual Basic has a long history, the first version of Visual Basic was released back in 1991, but the history of the language goes back even further than that. VB1 was the first RAD tool for creating Windows applications and created a new way of programming by drawing the user interface using a control toolbox. But the actual language syntax was an extension of the older QuickBasic language.

So VB had a large baggage even before the release of the first version of VB.Net or VB7 back in 2002. At that time the language went through a large transformation, so large that many people didn’t even recognized their favorite language anymore. I must admit that I was one among many that felt the transition to this new framework was painful, not so much because I had to learn a new framework because I enjoyed that part (and I still love to learn new programming languages). The reason was simply because it wasn’t backward compatible and it was a pain to convert an older VB6 application to use the new framework.

Microsoft did their best to make the transition to .Net as smooth as possible and added a lot of legacy functions in the Microsoft.VisualBasic.dll assembly, such as Left(), Mid(), Right(), Chr(), ChDir(), MsgBox() and so on. These functions aren’t really necessary since there are other ways of getting the same result, but it made the transition from VB6 a lot smoother.

A lot of other stuff was also added to this assembly, such as the ability to use late binding (with Option Strict set to Off) and later on many of the My namespace features points to methods within the Microsoft.VisualBasic assembly.

Other “features” also included in this assembly are On Error Goto and On Error Resume Next that still works in VB.Net. The main reason those are kept is probably because the Upgrade Wizard (that existed in versions prior to Visual Studio 2010), that converted VB6 code into VB.Net (at least partially), should be able to work. It’s to hard for a software wizard to convert On Error Goto and On Error Resume Next statements into good Try…Catch blocks.

So what does this have to do with the new compiler switch?

There is nothing wrong with the fact that VB has its own runtime library, after all C# and Visual C++ also have their own runtime assemblies. The difference is the size of these assemblies and what they contain. The Microsoft.CSharp.dll, which was added in .Net 4, contains the runtime builder that adds support for the dynamic keyword, while Microsoft.VisualBasic.dll contains a lot more, as discussed in the previous section.

– So does it matter?

No it doesn’t. At least not if you only want to write code for platforms that include the full .Net framework, such as desktop applications for Windows or ASP.Net applications for the web. But there are other platforms that doesn’t include the full framework, such as Windows Phone 7 or XNA for creating games that runs on the XBox. There can also be other third-party platforms that only contain parts of the .Net framework. When you have limited space for a custom implementation one of the last things you might want to add is the large Microsoft.VisualBasic.dll assembly.

– So what? If I don’t use any of the legacy functions, don’t care about late binding, and always use Try…Catch instead of the terrible On Error statements, why would I need this assembly? Can’t I write VB code without it?

Yes, you can. However the assembly is always referenced by default as soon as you create a VB project, but you can actually remove the reference when you compile the project. However you would need to use the command line compiler to do so. But (and yes there is a but and a rather big one) there is a problem with removing the VB assembly and the name of that problem is the CType operator.

Since CType is an operator and not a function the conversion will be done inline at compile time, or rather the compiler will try to do it inline but that is not always possible. Converting an integer to a double can easily be done during compile time but converting the generic System.Object to a less generic type is not possible until run-time. So there is a helper function in the VB assembly that does the conversion for you, but it can of course only do that if the assembly is available and you have a reference to it.

So the /vbruntime switch, that has existed in the command line compiler (vbc.exe) for a long time, has now been extended. Instead of just excluding the runtime assembly or using another assembly as the runtime, it will now be able to include the key VB runtime as a reference into your application. This will be a great help to get VB support faster for new platforms.

– So will we see VB support for the XNA platform anytime soon?

Well, it might not be that soon since apart from this compiler switch it will also require new templates, a lot of testing and so on, but yes, I think we will be able to use VB for XNA development sometime in a not so distant future.

Have fun!