Is the Microsoft.VisualBasic namespace "true .NET" code?
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?
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.
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
链接地址: http://www.djcxy.com/p/9050.html上一篇: 启动单个控制台应用程序