Microsoft.VisualBasic compatability

[snarfblam]

I was looking at the Microsoft.VisualBasic assembly with a reflection tool, and was surprised to see that nearly everything it contained simply wrapped another .Net function or class.

Microsofts take is that Microsoft.VisualBasic is part of the Visual Basic language, and Microsoft.VisualBasic.Compatibility is the for VB6 compatability, but looking through the functions, you notice that Hex() simply wraps the .ToString method of integral data types, and the Len function just returns the String.Length property. Even the Collection class seems to basically wrap the ArrayList class.

[VB]
Why?
Public Shared Function Hex(ByVal Number As Integer) As String
Return Number.ToString("X")
End Function

What is this??
Public Shared Function Int(ByVal Number As Integer) As Integer
Return Number
End Function

This is harldly justifiable...
Public Shared Function IsArray(ByVal VarName As Object) As Boolean
If (VarName Is Nothing) Then
Return False
End If
Return TypeOf VarName Is Array
End Function
[/VB]

It seems to me that all that the Microsoft.VisualBasic namespace provides is .Net functionality with different names to make VB6 users more comforatble in .Net. I dont use the Visual Basic namespace (even though I program in Visual Basic) but when the issue comes up of whether or not it is okay to use the VisualBasic namespace, I have always taken the stance that it is still part of the language and that it is mostly a matter of the programmers preference.

Now that Ive seen the decompiled code, though... I am actually a bit disturbed. It simply neednt exist. How about a section in MSDN that simply lists VB6 classes/functions and their .Net equivalent? When it comes to backwards compatability and upgrading, I think everything in Microsoft.VisualBasic should be moved to Microsoft.VisualBasic.Compatability.

 

[Denaes]

Its there to provide a wrapper to .Net functions for VB6 (ie non .Net) developers.

I try not to use it, but I still use vbTab... I think there were a few other things that I can do in C# but I cant do in VB.net without using the VB Compatability. There might be a way but I could never find it.

 

[snarfblam]

I know why its there, hence my suggestion for a MSDN article that lists .Net equivalents. The VisualBasic namespace doesnt help the learning curve much more than it would if you were to tell the VB6 programmers that so-and-so function in .Net is the exact equivalent. I suppose that my point was that it is rediculous to give programmers a set of functions that simply call another function for you. Why not just tell you the new .Net equivalents. I dont need Hex to call Int32.ToString for me; I can do that myself. I dont need Left to call String.SubString for me; I can do it myself.

There are a few things where the transition is a bit more complicated (for instance, files access). These I can understand still being around, but so many VB functions simply call other .Net functions, or at best reproduce their functionality. I personally have never run into anything in the Visual Basic namespace that I couldnt do without it, and the result is usually the same amount, if not less, work and coding on my part.

 

[john]

I agree it would be nice to have a cross reference like that. What tool were you using? It might be possible for us to do one.

You might find this thread ineteresting as well:
http://www.computerhelp.forum/showthread.php?t=204905

As I said over there I think the Microsoft.VisualBasic namespace is fine to use. What annoys me is when I have to dig through code where the programmer used things from that namespace as well as the .NET equivalents in the same code. I have no problems with it being used if that is how someone is comfortable but I prefer consistency. The Microsoft.VisualBasic.Compatibility namespace should be avoided however since it will likely be dropped at some point in the future.

 

[Napivo1972]

It

 

[PlausiblyDamp]

Personally I tend to avoid the VB6 way of doing things in .Net as I use both C# and VB (I equally try to avoid things that are C# specific) and having to remember two ways of doing something rather than one just leads to confusion (or stupid mistakes anyway).
Saying that several of the functions in the Microsoft.VisualBasic namespace do additional safety checks that you would be required to perform yourself if going the pure .Net route.
The Microsoft.VisualBasic.Compatibility namespace on the other hand is a horrible idea for anything other than code migrated with the wizard (which is an even worse idea anyway). Things like the Drive / Folder list controls, the various Control Array collections, twip conversion routines, wrappers around non zero based arrays etc are awful things to work with.
I also have to agree with Orbity on code when both ways are used without any clear reason.

 

[snarfblam]

I used Lutz Roeders .Net Reflector, which I got here: http://www.aisto.com/roeder/dotnet/

Microsoft.VisualBasic namespace do additional safety checks

Yes, many of the functions do additional saftey checks, but most of these safety checks one would (and should) normally do himself anyways. Either that or they are checks you normally wouldnt need. For example, the IsArray function first checks if the reference is a null reference, and if so, returns false. I personally would never think of passing a null reference to IsArray in the first place. If there was any possibility of the variable being a null reference, I would check first. And personally, I would want a null reference exception thrown if I passed a null reference to IsArray so that I would know if I were doing something wrong. (I assume that this behavior is there for consistancy with VB6, but that was just an example off the top of my head.)

You might find this thread ineteresting as well:
http://www.computerhelp.forum/showthread.php?t=204905

I have read this article, which makes some good points. Id like to point out an inaccuracy in the article, though. It states that conversions are inlined and make no reference to the Visual Basic namespace. Some conversions can not be inlined, however, such as strings to numeric types, and vice-versa. And rather than simply calling the .Parse and .Tostring methods, they call functions in the VisualBasic namespace. Look at the IL below (this is what my CStr got compiled to).

[VB]
L_00c7: call string [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.StringType::FromInteger(int32)
[/VB]

The implicit call to the VB namespace doesnt bother me. What does bother me is the fact that they use their own function, which in turn simply calls the appropriate .ToString function. I dont see the necessity. This call to Int32.ToString could be inlined.

[VB]
.method public static string FromInteger(int32 Value) cil managed
{
// Code Size: 10 byte(s)
.maxstack 3
.locals (
string text1)
L_0000: ldarga.s Value
L_0002: ldnull
L_0003: ldnull
L_0004: call instance string int32::ToString(string, [mscorlib]System.IFormatProvider)
L_0009: ret
}
[/VB]

Oh, and btw,
vbNewLine = Environment.NewLine.


And like I said, in the past I would normally say that using Microsoft.VisualBasic is okay to use. Microsoft says it is part of Visual Basic. But when you really look at it, all Microsoft.VisualBasic is is .Net for dummies. It just wraps existing functionality with those familiar old names, and performs checks that I personally wouldnt expect or need it to do for me.

 

[Napivo1972]

marble_eater,

Thank you I have been looking for that for hours

 

[Denaes]

I used it on the visual basic namespace too and it tought me a great deal about getting things done the .net way.

Trouble is it can see any code written in .net. That of course is a knife that cuts both sides

 

[john]

...
I have read this article, which makes some good points. Id like to point out an inaccuracy in the article, though. It states that conversions are inlined and make no reference to the Visual Basic namespace. Some conversions can not be inlined, however, such as strings to numeric types, and vice-versa. And rather than simply calling the .Parse and .Tostring methods, they call functions in the VisualBasic namespace...

Im the one who brought up the part about inlining and Id like to point out what I actually said:

Ive done a little testing with it and it looks like the VB style conversion functions inline whenever possible but not always.

The reason I brought up the inline stuff in the first place was because of the other thread I linked to in there:
http://www.computerhelp.forum/showthread.php?t=207586

It was discussing just what happens when you use this code:

Const myString As String = Chr(27) & "P"

 

[snarfblam]

If you want to protect your source code from such reflection utilities, there are always obfuscators. Supposedly, the best obfuscators generally make your assemblies unreadable with reflection tools and can improve performance. It would seem to me that to be unable to reflect on an assembly could cause some problems, though. Ive never tried one myself; they cost money.

 

[realolman]

I was looking at the Microsoft.VisualBasic assembly with a reflection tool, and was surprised to see that nearly everything it contained simply wrapped another .Net function or class.

I doubt I can articulate my thoughts on this very well, but...


It has seemed to me for a long time that "things" are increasingly too dependent upon language, when in reality the language is dependent on the physics of the hardware. Eventually, doesnt it all sift out to turning transistors on and off somewhere?

Since the whole thing stems from the same place, why can there not be one programming language?

a sort of Esperanto? ... Computeranto!...BillGateseranto?

BTW
As someone from VB6 land, I havent felt at all warm and fuzzy about any support or compatibility from .NET. I think it sucks. After programming w/ Basic for 20 some years, its been months and I dont seem to be able to bring myself to relearn the language. I think Ill probably just fade away.


But thats another thread. Please dont hammer me about that.

 

[snarfblam]

Since the whole thing stems from the same place, why can there not be one programming language?

C++ is great for some things. Its portable; its executes fast. VB is great for some other things. Its ideal for RAD. Some languages are better for web related apps (and then some are applicable only to the web period). .Net languages give you access the the very useful .Net framework and managed code and data, where as other languages can suit a more common denominator of end users. The reason that there are so many different languages is that they are all suited to different tasks.