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.

Microsoft's 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.

'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

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 don't 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 I've seen the decompiled code, though... I am actually a bit disturbed. It simply needn't 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]

It's 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 can't 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 doesn't 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 don't need Hex to call Int32.ToString for me; I can do that myself. I don't 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 couldn't 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.xtremevbtalk.com/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’s now 3 months I switched from VB6 to vb.net. Quite frankly I can’t program in vb6 anymore.

I rather soon after a week or 2 threw out the entire visual basic namespace and started working under option strict. Of course at first you have problems with not having left and mid. having to convert values by hand. and so on

It took me about 3 more weeks to feel at home in .net and I must say my coding is so much clearer as it used to in vb6.

However I still miss some vbConstants like vbNewLine as I haven’t found a replacement for some. So I maintain my own set of constants until I find the correct way.

 

[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 Roeder's .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 wouldn't 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.xtremevbtalk.com/showthread.php?t=204905

I have read this article, which makes some good points. I'd 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).

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

The implicit call to the VB namespace doesn't 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 don't see the necessity. This call to Int32.ToString could be inlined.

.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 
}

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 wouldn't expect or need it to do for me.

 

[Napivo1972]

marble_eater,

Thank you I have been looking for that for hours…. I must be blind

Reflector is a very nice tool I use it too but I try to keep it out of the hands of novices…. Oh well doesn’t matter sooner or later everyone will know about this great utility and use it to view other peoples code.

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….. I have used this to translate .net C code to VB and visa versa.

 

[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….. I have used this to translate .net C code to VB and visa versa.

Two good reasons to use it as a tool.

I've found the way most reflectors work, they're really useful in looking at a procedure, but it would take a LOT of work to piece together how an application works if you were to view one. Not newbie friendly at all.

 

[John]

...
I have read this article, which makes some good points. I'd 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...

I'm the one who brought up the part about inlining and I'd like to point out what I actually said:

I've 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.xtremevbtalk.com/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. I've 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, doesn't 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 haven't 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, it's been months and I don't seem to be able to bring myself to relearn the language. I think I'll probably just fade away.


But that's another thread. Please don't 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. It's portable; it's executes fast. VB is great for some other things. It's 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.