Is the Microsoft.VisualBasic namespace "true .NET" code?

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

There is a bunch of .NET code that Microsoft actually just wraps COM functionality. I'm not a licensing guru, but you could always grab Reflector and take a look at that namespace and see for yourself.

Answer 2

I believe they all compile to the very same bytecode.

Here's my reference: http://www.codinghorror.com/blog/archives/000128.html

Answer 3

I think a good place to start would be the MSDN documentation provided by Microsoft about VB.net

http://msdn.microsoft.com/en-us/library/2x7h1hfk.aspx That link would be the latest visual studio 2008 write up about the language.

VB compiles the same as C# under the CLR so I do not get where your consultant is coming from here.

Answer 4

The statement "Microsoft no longer supports Visual Basic" could mean several things, since there are several versions of Visual Basic - VB 1 though to 6, VBA and VB.NET.

The statement "Microsoft no longer supports Visual Basic.NET" would be big news if it was true, but it isn't. (I checked on google). Support for VB6 has ended, but VB.Net is still very much alive and gaining new features.

VB.Net compiles to MSIL bytecode that depends on some of the the .Net libraries, depending on which .net framework classes you use. Some of those libraries are not written in pure .Net, or are just wrappers around the Windows API. This is needed, since those features that are not built into .net (e.g threading) have to be exposed to it in a controlled fashion.

Exactly the same is true of C#. The runtime doesn't really care which language generated the MSIL that it executes.

Answer 5

Microsoft's goal is to make VB .NET and C# the same language with different syntax. This is true. However changes always creep in like VB9's new handling of XML literals. What he's asking is have they reimplemented all the OLD VB6 and previous functionality as .NET managed code. My guess would be no.

Answer 6

Use .NET Reflector and take a peek into it. I do this frequently. 9 out of 10 calls in the Microsoft.VisualBasic namespace are just wrappers around .NET methods.

Your consultant is doing what consultants do best: showing off that he exists to make your budget larger. MS doesn't support VB6 anymore, but the fact that VS 2008 has VB .NET should indicate that they will support VB .NET for at least a few more years.

Personally, I treat Microsoft.VisualBasic like a facade over other .NET classes. I use it when it's a personal project and I can get my work done more quickly and easily than using BCL classes. A good example is Microsoft.VisualBasic.Strings.Right compared to String.Substring. However, for many of the functions (like Val) in the VB namespace, there are more robust and powerful versions in the less language-specific sections of the framework. If I'm writing code for work, I don't use the VB libraries. This makes it so that C# developers unfamiliar with VB will not have a harder time understanding my code.

Answer 7

I've not done much with VB.NET (more with C#), but as far as I was aware, they both compile to the same bytecode, and are hence interpreted identically by the .NET runtime, and that they are functionally equivalent, just syntactically different.

VB.NET seemed a lot different from VB6 when I last used it, though.

Answer 8

VB.NET code is not directly compiled to binary. It's compiled to IL (Intermediate Language) just like C#.

What does that mean is that whatever you are building in VB.NET, it will be reusable in C# projects without any problems.

I wasn't able to find any links directly related to what you ask. The main reason is that VB.NET is part of a new actively developed framework. There is no plan to make that language obsolete. Whatever the other consultant is saying.

Answer 9

As far as I know, VB.NET is 'true .net' code, as you put it. There are a lot of different languages (C#, VB.NET, F#, Cobol.NET, etc) that all 'compile' into IL code. That IL code is what is actually run by the .NET VM and interpreted to machine code. The objects that you interact with between the languages are still the same underlying .NET objetcs.

For example, in C#:

DataTable dt = new DataTable();

Compiles to the exact same IL code as the equivalent in VB.NET:

Dim dt as DataTable = new DataTable()

In fact, in decompiler tools like .NET Reflector, that look directly at the IL code, you can have it display the output in C# or VB.NET, whichever you are more comfortable with.

This also means that I can write one class library in VB.NET "myVbCode.dll" and it is directly compatible with one written in C# "myCSharpCode.dll". In fact both of the DLLs will only contain the compiled IL code.

There may be some outlying exceptions to all this, but fundamentally that is how it works.

Answer 10

A direct answer to your question would be that VB.NET is just as much "true .NET code" as C# is.

Sure, there are syntax features in both languages that aren't directly available in the other (for instance, VB.NET has some XML features built into the syntax that C# doesn't), but there is nothing you can do in VB.NET you can't do in C#, or vice versa, at least to my knowledge.

I'd say that if you have experience in VB, then the transition to VB.NET will of course be easier than the one to C#.

Answer 11

Like some functionality in the FCL, some of the Microsoft.VisualBasic namespace code is written in managed code, some of it wraps calls to unmanaged code.

There's certainly no dependency on the vb6 runtime and it certainly isn't installing the vb6 runtime quietly under the bonnet.

You should load up .NET Reflector and take a peek at the code in the Microsoft.VisualBasic namespace.

If you want to go on using functionality in this namespace from C# then keep doing so, it's not going away. Some code may get marked as deprecated/obsolete but I expect in 15 years time you'll still be able to run the same apps using Microsoft.VisualBasic functionality without any trouble.

Updated: As well as using .NET reflector you can now see/debug the source Microsoft.VisualBasic namespace/Microsoft.VisualBasic.DLL code:

http://blogs.msdn.com/vbteam/archive/2008/01/19/source-code-of-visual-basic-runtime-has-been-released-to-public.aspx

Go grab the framework mass downloader and peruse the code at your leisure:

http://www.codeplex.com/NetMassDownloader

Answer 12

As OwenP said, most of the calls in the Microsoft.VisualBasic namespace are just wrappers around existing .NET functionality. So why create wrappers?

When VB.NET was created, Microsoft wanted developers to be able to import existing VB6 projects into .NET. That was only feasible if the VB6 functions and method calls had matching functionality in VB.NET. So they created the Microsoft.VisualBasic namespace to map that VB6 functionality to .NET functionality. (Pure speculation, but it makes sense)

As .NET has progressed into new versions, they couldn't remove the Microsoft.VisualBasic namespace - lots of code is probably still using it. So it's still there.

Besides, you can write VB.Net code without even using the Microsoft.VisualBasic namespace. (And as Kev implied, you can use the Microsoft.VisualBasic namespace from C#.) VB.Net is just a language, the .NET framework remains the same.

Answer 13

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.