Question

My dev team is getting ready to start a new project. The shop has been a ‘VB shop’ since the days of VB3, but the prevailing opinion now is that we’re a ‘.NET shop’ and since C# was created specifically for .NET, whereas VB.NET was a retrofit, we’ve decided to move forward writing C# only. The controversy revolves around the question of whether the Microsoft.VisualBasic namespace has a legitimate place in new development or if it is only for backward compatibility for VB6 (and older) code. A further, and more interesting question is whether the code ‘under’ the Microsoft.VisualBasic namespace is even .NET code of if it is really the old VB runtime carefully packaged in a .NET wrapper, making it in fact a COM interop control (similar to how WinForms wraps the non-.NET Win32 windowing API but exposes only .NET APIs for consumption).

To make this even more confusing, our dev team has a Microsoft Consulting Services consultant telling us Microsoft no longer supports Visual Basic, including the VB runtime underlying the Microsoft.VisualBasic namespace.

What I’m looking for are links — preferably to unimpeachable Microsoft sources — to documentation that definitively answers this question one way or the other. I’ve already tried several search permutations on Google and not gotten any closer to getting to the bottom of this question.

EDIT: Apparently I didn’t make my question clear. I’m not asking if VB.NET is true .NET code. I’m trying to determine if whatever is ‘under’ the Microsoft.VisualBasic namespace is .NET code or if it’s the old VB6 runtime carefully packaged and exposed as .NET code. Someone already said that 9/10 of the namespace simply wraps code from elsewhere in .NET; what about that other 1/10?

Answer 1

Microsoft.VisualBasic.dll <> Microsoft.VisualBasic.Compatibility.dll !!!

(or, if you prefer, Microsoft.VisualBasic.dll != Microsoft.VisualBasic.Compatibility.dll; )

The Microsoft.VisualBasic.Compatibility namespace is exclusively for use by the VB6 upgrade wizard, may be removed in future versions, and should not ever be used for new development.

The Microsoft.VisualBasic namespace is absolutely, 100% true .Net, fully supported, and will be around as long as .Net is around.

A few relevant links:

• Discussion: Is Microsoft.VisualBasic deprecated?
• Article: Achieve pure .NET development with VB.NET
• See comments on this MSDN VBFAQ blog post

Edit: Added the official word from this MSDN article:

The Visual Basic Runtime provides the underlying implementation for global Visual Basic functions and language features such as Len, IsDate, and CStr. And though the new Visual Basic Runtime provides similar facilities as its predecessors, it is entirely managed code (developed in Visual Basic .NET) that executes on the common language runtime. Furthermore, the Visual Basic Runtime is part of the .NET Framework, so it is never something separate that your application has to carry or deploy.

and

The Visual Basic 6.0 Compatibility library is distinct from the Visual Basic Runtime. The Microsoft.VisualBasic.Compatibility namespace is used by the tools that upgrade Visual Basic 6.0 code to Visual Basic .NET. It is a bridge to support Visual Basic 6 features that are not directly supported by the .NET implementation of Visual Basic. Unlike the Visual Basic Runtime, the compatibility library is not implicitly referenced by all Visual Basic .NET applications. When you upgrade a Visual Basic 6 project to Visual Basic .NET, the upgrade wizard adds a reference to Microsoft.VisualBasic.Compatibility.

The compatibility classes should not be used for new development. The Microsoft.VisualBasic.Compatibility namespace adds a layer of complexity to your Visual Basic .NET application and introduces some minimal performance costs that could be eliminated by recoding portions of the application. In addition, the Compatibility namespace often contains many classes that wrap COM objects, and as stated earlier, depending on COM objects is not as optimal as a pure managed implementation.