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?
Though C# and VB.NET are syntactically very different, that is where the differences mostly end. Microsoft developed both of these languages to be part of the same . NET Framework development platform. They are both developed, managed, and supported by the same language development team at Microsoft.
VB.NET is also known as Visual Basic.NET. It stands for Visual Basic . Network Enabled Technologies. It is a simple, high-level, object-oriented programming language developed by Microsoft in 2002.
The My namespace in Visual Basic exposes properties and methods that enable you to easily take advantage of the power of the . NET Framework. The My namespace simplifies common programming problems, often reducing a difficult task to a single line of code.
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:
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With