Microsoft.VisualBasic vs System

I'd suggest that anyone who has ever advocated the non-use of anything from the Microsoft.VisualBasic namespace reads this article. Personally, I found it rather enlightening. There is still the issue of future support for VB6-style methods from the Microsoft.VisualBasic namespace but, from what that article says, that is the ONLY issue. And there is no specific indication that that will ever be an issue anyway. I've now pretty much weaned myself off Microsoft.VisualBasic, so I will still use a System based method if there is one available, but I will not hesitate to use Microsoft.VisualBasic in future if it seems appropriate. Nor will I berate anyone else for doing so.

Edit:
I guess the other issue may be lack of code portability to other .NET languages. I don't think that that is foremost in your average VB developers mind, though. For those who do want as much code portability as possible, stick to System, and don't ever let me see you use "?:" in C#. :)

I'm referring most specifically to the Visual Basic Runtime section.

Quote:

---

Originally Posted by jmcilhinney

don't ever let me see you use "?:" in C#. :)

---

And why not?

Quote:

---

Originally Posted by crptcblade

And why not?

---

Because there is no equivalent in VB. I said that a little tongue-in-cheek, but if you suggest not using convenient features of VB for the purposes of code portability then you must surely forgo the language-specific conveniences found elsewhere. I don't really think it is a bad idea to use "?:", but by the same logic it must be OK to use members of Microsoft.VisualBasic.

Quote:

---

Originally Posted by jmcilhinney

don't ever let me see you use "?:" in C#. :)

---

i might be completely wrong on this (im not completely sure i know what the symbols mean)...

but isn't that the same as the vb "Iff()" statement?

Quote:

---

Originally Posted by jmcilhinney

Because there is no equivalent in VB. I said that a little tongue-in-cheek, but if you suggest not using convenient features of VB for the purposes of code portability then you must surely forgo the language-specific conveniences found elsewhere. I don't really think it is a bad idea to use "?:", but by the same logic it must be OK to use members of Microsoft.VisualBasic.

---

I've always been of the opinion that Microsoft.VisualBasic is not a bad thing. I use the functionality as sparingly as possible, but its nice to have when you just feel like doing things the easy way.

I'm sure many will come along and go on and on about how wrong I am, but they can all kiss my bum.

:afrog:

Quote:

---

Originally Posted by tr333

i might be completely wrong on this (im not completely sure i know what the symbols mean)...

but isn't that the same as the vb "Iff()" statement?

---

IIf is under the Microsoft.VisualBasic namespace.

See what I mean?

:afrog:

Quote:

---

Originally Posted by tr333

i might be completely wrong on this (im not completely sure i know what the symbols mean)...

but isn't that the same as the vb "Iff()" statement?

---

Also, IIf is a function, which means that all arguments get evaluated regardless of the outcome. The C# ternary operator ?: short-circuits if the condition is true. As an example this code

Code:

---

int strLen = myString == null ? 0 : myString.Length;

---

is fine in all circumstances while this code

VB Code:

Dim strLen As Integer = IIf(myString Is Nothing, 0, myString.Length)

will throw a NullReferenceException if no value has been assigned to myString because it will try to evaluate myString.Length regardless.

Quote:

---

Originally Posted by crptcblade

I'm sure many will come along and go on and on about how wrong I am, but they can all kiss my bum.

---

Nope, not going to say I word...no need...you already know you're wrong, so me ranting at you won't solve anything ;)
It's bad bad bad...and you know it :D

I dunno how it can be quicker to write.
VB6:

VB Code:

Dim lngIndex As Long
   lngIndex = CLng("453324")

VB.NET

VB Code:

Dim Index As Integer
   Index = CType("453324", Integer)

OK, so the .NET code is a little more excessive. But how about:
VB6:

VB Code:

Dim dteMeeting As Date
   dteMeeting = DateAdd("h", 1, dteMeeting)

VB.NET

VB Code:

Dim MeetingDate As Date
   MeetingDate = MeetingDate.AddHours(1)

In the above case the .NET code is WAY better than VB6 code.
I think it's 6 and 2 3's when it comes to the speed of writing code.

It just seems daft to use something in Live development that was only added into .NET to aid conversions.

How does one go about removing the Microsoft.VisualBasic runtime from an app? I can right click the project, properties, imports and remove it manually there. But i don't want it loaded in the 1st place. It's really irritating going through every project and removing it.
Anyone?

Woof

Isnt there a template that the new projects are created from that you could modify and take out the MS.VB namespace?

VB Code:

Dim Index As Integer = CType("453324", Integer)

;)

Yup, you are correct with that line of code.
The reason I didn't write my examples like that was because some smart arse would come on and say "well yea, it's shorter code, because VB6 doesn't allow you to do that", so I kept them almost identical

;) To you too :D

Wof

Quote:

---

Originally Posted by RobDog888

Isnt there a template that the new projects are created from that you could modify and take out the MS.VB namespace?

---

that's what I am trying to find out.

Woof

But what about template projects? They have to be generated somehow.

Thanks for calling me Smart :D :lol:

After moving from VB6 to VB.NET it took a while growing accustomed coding 'the .NET way'. But now that I am there, I am not going back. For example: using myString.Length looks so much neater than Len(myString) in my opinion.

Or i.ToString("000.0") versus Format(i, "000.0")

(by the way: learning which .NET methods exits and how to use them goes quickly once the VisualBasic reference is gone)

Woka - yes, there is a way to remove it.... but it's not in the project templates.... it's actualy in the options area of the IDE itself.... I forget where just exactly, but there's a place where you cna define auto imports for new projects.

Tg

I have searched and searched and cannot see anything in options :(

WOka

Here's a quote from the article I referenced, which it would appear some of you have not read, or have read and chose to ignore:

Quote:

---

If for some reason you choose to use only System namespace classes instead of Visual Basic Runtime features and carefully avoid all language features supported by the Visual Basic Runtime, you can end up with IL that does not use any resources from the Visual Basic Runtime. You need to be aware, however, that you cannot choose whether or not your program references the Visual Basic Runtime, even if your programs do not use it. Although you can remove the project-wide import of the Microsoft.VisualBasic namespace in Visual Studio .NET, the compiler still requires the presence of Microsoft.VisualBasic.dll in order to support language features that could appear in your code (such as late binding and string comparison). Microsoft.VisualBasic.dll is part of the Framework so it is reasonable for the compiler to assume it will be available. Furthermore, your assembly manifest will still reference the Microsoft.VisualBasic assembly although it is not loaded at run time if its resources are not used (meaning no extra overhead is incurred for the reference).

---

I've trained myself to use System methods, so I know what you mean by:

Quote:

---

using myString.Length looks so much neater than Len(myString) in my opinion.

---

but if you remove all bigotry and bias, how can that seriously be true? The article also says that the Len() function actually calls String.Length anyway, but it simply does things like check for a null reference first, which your code should do if it's written properly. So tell me, which is neater? This:

VB Code:

Dim myInt As Integer
 
If myString Is Nothing Then
    myInt = 0
Else
    myInt = myString.Length
End If

or this

VB Code:

Dim myString As Integer = Len(myString)

Wokawidget, I'm sorry but your first example is flawed. CLng is just as much a part of VB.NET as CType is. Notice that when you use either in the IDE they turn blue. That's because they are both VB.NET keywords, i.e. part of the language and nothing to do with any namespace. I challenge you to find any literature that connects CLng, CInt, etc. to the Microsoft.VisualBasic namesapce. Believe me, I've looked. CType was actually added for "compatibility" so you have a general way to convert objects that resembles the existing CInt, CStr, etc. when a specialised method does not exist. If you want to be "pure .NET" (which is a term I will only use with sarcasm from here on), surely you have to use the System.Convert class, which has methods ToInt32 (equivalent to CInt), ToString (CStr), ChangeType (CType), etc.

Frankly, advocating the non-use of the Microsoft.VisualBasic namespace comes down to bigotry and is a way for VB.NET developers to feel superior to VB6 developers. The members of Microsoft.VisualBasic have been named and implemented to behave the same way as corresponding methods used in VB6, but they are not the same methods. They are implemented using the .NET Framework and often call the very properties and methods that we've being recommending as being superior. If you haven't read the article I suggest you do. It actually quotes at least one case where using the VB Runtime method produces superior performance to the System method.

Further, does anyone here recommend not using the VB Runtime and then go and use modules? If you think that anything VB6-like is bad then surely modules must be the height of all evil? They are not, of course, because they have been re-implemented for VB.NET to conform to the OO standards of VB.NET, just like the VB Runtime.

Quote:

---

Originally Posted by jmcilhinney

I'd suggest that anyone who has ever advocated the non-use of anything from the Microsoft.VisualBasic namespace reads this article. Personally, I found it rather enlightening. There is still the issue of future support for VB6-style methods from the Microsoft.VisualBasic namespace but, from what that article says, that is the ONLY issue. And there is no specific indication that that will ever be an issue anyway. I've now pretty much weaned myself off Microsoft.VisualBasic, so I will still use a System based method if there is one available, but I will not hesitate to use Microsoft.VisualBasic in future if it seems appropriate. Nor will I berate anyone else for doing so.

Edit:
I guess the other issue may be lack of code portability to other .NET languages. I don't think that that is foremost in your average VB developers mind, though. For those who do want as much code portability as possible, stick to System, and don't ever let me see you use "?:" in C#. :)

---

It's funny how this article came up again, we had a conversation about it some time ago.

My favourite example from this article:

Quote:

---

The Mid, Left, and Right methods in Visual Basic .NET all call String.Substring. However, the Visual Basic Runtime methods are optimized to prevent string allocation for some common cases. For example, the following simple case is 85 percent faster using the Visual Basic Runtime methods versus the System method:

VB Code:

Dim s1, s2 As String 
s2 = "abc"
 
' fast, prevents string allocation
s1 = Left(s2, 3)
' SubString is not optimized for this case
s1 = s2.SubString(0, 3)

Recommendation: Use Mid, Left, and Right, which are found in the VisualBasic namespace.

---

I'll risk re-iterating a small code fragment:

VB Code:

Dim i As Integer
 
        Dim s1 As String, s2 As String
        s2 = "abcdef"
 
        Dim sw As StopWatch = New StopWatch()
 
        For i = 1 To 100000
            s1 = Mid(s2, 1, 3)
        Next
 
        Debug.WriteLine("Time1: " + ((sw.Peek() / 10)).ToString + " msec")
 
        Dim sw2 As StopWatch = New StopWatch()
 
        For i = 1 To 100000
            s1 = s2.Substring(0, 3)
        Next
 
        Debug.WriteLine("Time2: " + ((sw2.Peek() / 10)).ToString + " msec")

...where StopWatch is a class that can be found here. Tests on my machine without using the debugger (start project without debugging) show that the .Substring() method is definitely faster, at least for small and medium sized strings, haven't tried anything other than a few hundred chars long. So, unless someone shows to me the error in the above timing code, I'll completely ignore the text of that article as being plain wrong. BTW, I don't really hate the VB namespace (how can I? It's included in all VB projects whether I want it or not). All I'm thinking is that people should be aware that Mid isn't the same as .Substring. My personal reasons for prefering .Substring to Mid is that it looks cleaner to me and my C# colleagues also know what my code means.

Quote:

---

Originally Posted by jmcilhinney

Frankly, advocating the non-use of the Microsoft.VisualBasic namespace comes down to bigotry and is a way for VB.NET developers to feel superior to VB6 developers.

---

Yes...that's right :rolleyes:
I am no where near as good at .NET as I am at VB6, so am I putting myself down?
Ok, I am gonna do some reading on it over the next few days.
I am only going off what I have been taught...on courses, by senior developers and some very good contractors. And in first light it seems they would be making sense...why wouldn't they?

However, after your little rant (:D) I am going to toddle along and read up on it.

Woof

Should we take a vote on this? :D

according to ntg's info, we still should be writting .NET code and not MS.VB namespace. :thumb:

ntg, did you test the code that the article quotes? It says that the VB Runtime functions are optimised for some common cases, not all cases. I'd guess that those common cases are when the substring will actually be the whole string, and also perhaps when Mid actually starts from the beginning or finishes at the end of the string. You don't have to use the Runtime function if you don't want to, and not doing so will save the extra function call, but please do not criticise someone else who chooses to do so. Again, I challenge you to find some literature that indicates with facts, rather than opinion, that using VB Runtime functions is a bad thing. There may be specific instances of certain functions that should be avoided for specific reasons, but I find no compelling reason to avoid the VB Runtime in general. Like I said, I'm in the habit of using System functions anyway. I'm not going to suddenly start using MsgBox, but I will happily use IsDate as long as I'm on .NET 1.1. I'm sure that more functionality will be added to the System classes over time, like DateTime.TryParse, but it still doesn't mean that using the VB Runtime is wrong. Until Microsoft indicates that they intend to remove certain functionality from the VB Runtime, using it is as legitimate as using any other library.

Quote:

---

Originally Posted by RobDog888

Should we take a vote on this? :D

according to ntg's info, we still should be writting .NET code and not MS.VB namespace. :thumb:

---

This is another example of what I'm talking about. I've been guilty of doing the same thing, I have to admit, but using the VB Runtime IS writing .NET code. All VB Runtime functions are implemented using the .NET Framework, and many even use the very same properties and methods internally that we've been suggesting they be replced with.

While now it might be perfectly fine to use it, who's to say support might not be pulled in later versions of .NET? Or for that matter, who's to say .NET won't be pulled years down the road for Cappucino. I think the best thing anyone can do is learn both methods, and try to get in the habit of not using compatibility objects - in their own best interests. I mean, if you say on a resume you have .NET experience, and what you really have is VB6 experience in a .NET IDE, then what happens when someone hands you "Pure .NET" code and you have to edit it? Granted, most of the naming conventions are pretty self-explanatory, but it could add time to your code-fixing, etc, and you might look a little slow or inexperienced in your new job.

Bill

Quote:

---

Originally Posted by conipto

While now it might be perfectly fine to use it, who's to say support might not be pulled in later versions of .NET? Or for that matter, who's to say .NET won't be pulled years down the road for Cappucino. I think the best thing anyone can do is learn both methods, and try to get in the habit of not using compatibility objects - in their own best interests. I mean, if you say on a resume you have .NET experience, and what you really have is VB6 experience in a .NET IDE, then what happens when someone hands you "Pure .NET" code and you have to edit it? Granted, most of the naming conventions are pretty self-explanatory, but it could add time to your code-fixing, etc, and you might look a little slow or inexperienced in your new job.

Bill

---

While that all makes perfect business sense, it still doesn't alter the fact that if you are considered an inferior programmer for using VB Runtime functions, that is due to prejudice rather than any real measure of ability. I know jack about remoting, reflection, etc. but am I a better programmer than someone who does but has a tendency to use MsgBox? We should all strive to know as much as we can about the tools we use so that we can create the best software we can. That means strinking the best balance of developer productivity and software performance. There is nothing wrong with pointing out an alternative to someone, but implying that their current method is wrong, or less correct, is doing them a disservice.

Again, the term "pure .NET", which I've used myself on many occassions, is a misnomer in this case. The VB Runtime is as "pure .NET" as any System-based code because it is implemented using managed code. The functions have been named to correspond to functions found in VB6, and they have been implemented such that their behaviour is the same or nearly the same, but the VB.NET Runtime is purely managed code. Only unmanaged code is not "pure .NET".

Quote:

---

Originally Posted by jmcilhinney

ntg, did you test the code that the article quotes? It says that the VB Runtime functions are optimised for some common cases, not all cases. I'd guess that those common cases are when the substring will actually be the whole string, and also perhaps when Mid actually starts from the beginning or finishes at the end of the string.

---

Right. But the conclusion doesn't point out which are those special cases as it doesn't make any distinction between Left/Right and Mid. After playing with the timing code to randomly generate small/large strings and take substrings of random lengths using both Mid and Substring, I can tell you that Substring is faster 95% of the time, especially if the string to copy is much smaller than the whole string. Now, if that's correct and the timing code doesn't have an error, I would describe the statement "The Visual Basic Runtime Mid method is optimized to prevent string allocation for some common cases" (thus faster) as not being supported by the evidence. This may be true for special cases and/or for the Left and Right methods but the written conclusion doesn't distinguish between special cases and general use.

Quote:

---

Originally Posted by jmcilhinney

You don't have to use the Runtime function if you don't want to, and not doing so will save the extra function call, but please do not criticise someone else who chooses to do so.

---

I don't think I criticized you or anyone else for using the VB runtime and as far as I'm concerned you can do as you please. But this is a forum and you don't mind if I state my personal preference, right? Personally I don't really care if the VB runtime is slower or faster than the System namespace. However, I do find the String.Substring notation better because it more readily prompts me to the notion of a method call of an object or a wrapper class - plus, C# guys won't ever get IIf(Mid(s,2,1)='A', True, False). Again, that's only my humble opinion.

Quote:

---

Originally Posted by jmcilhinney

...but I find no compelling reason to avoid the VB Runtime in general

---

I wouldn't put down a programmer simply because she used MsgBox instead of MessageBox - rather I'd focus on the real value of her work. However, since in my shop there are people around that don't know VB, I will always prefer the System namespace over the VB namespace if I can get away with it. And, although the probability seems rather remote, I can't entirely rule out the possibility that at some point MS may decide to make some changes to the VB namespace that will break forward compatibility with existing code - I really don't want to have to go through such a situation again.

Quote:

---

Originally Posted by jmcilhinney

Again, I challenge you to find some literature that indicates with facts, rather than opinion, that using VB Runtime functions is a bad thing

---

It's funny but this MSDN page states that the MessageBox.Show() is preferrable to MsgBox(), although it really never says why. Is that considered literature? They're the same guys that posted the initial article you referenced, the same that have written this MSDN article for IMessageSink with sample code that doesn't compile (hell, I won't even bother to try and find that Share class anywhere else in MSDN).

Quote:

---

Originally Posted by conipto

While now it might be perfectly fine to use it, who's to say support might not be pulled in later versions of .NET? Or for that matter, who's to say .NET won't be pulled years down the road for Cappucino. I think the best thing anyone can do is learn both methods, and try to get in the habit of not using compatibility objects - in their own best interests. I mean, if you say on a resume you have .NET experience, and what you really have is VB6 experience in a .NET IDE, then what happens when someone hands you "Pure .NET" code and you have to edit it? Granted, most of the naming conventions are pretty self-explanatory, but it could add time to your code-fixing, etc, and you might look a little slow or inexperienced in your new job.

Bill

---

This is how I feel also. I just cant bring myself to use the MS.VB namespace because it just doesnt seem to be
a good practice to keep writting "old" code. Heck what if we had a BASIC namespace because MS provided forward
compatibility across the 6 versions of VB. Would you write code using the BASIC namespace if it had the smae scenerio
as MS.VB? I think not because you would make a unconscience decision that it is best if you take advantage of the newer
technology because you dont know what the future would be for the "next" version. ;)

Quote:

---

Originally Posted by ntg

I don't think I criticized you or anyone else for using the VB runtime and as far as I'm concerned you can do as you please.

---

I meant "you" in the general sense. I didn't mean to imply that you had personally criticised me.

My main issue is that some people, including myself, have been making statements like "it is preferable not to use the Microsoft.VisualBasic namespace" with an air of authority when that stance is based almost solely on opinion rather than facts. There is no more concrete reason to believe that support for Microsoft.VisualBasic will be reduced than to believe that support for ceratin System namespaces will be reduced. As an example, System.Web.Mail has already been deprecated in .NET 2.0. To the best of my knowledge, .NET 2.0 has not reduced support for the VB Runtime in any way. Basically, nothing is really safe, so that argument doesn't really hold water for me anymore. The reason these VB Runtime functions exist is to continue VBs tradition of being simple to use, while still adding desireable features of other languages through OOP and the .NET Famework. If you believe that Microsoft is going to remove all or much of the Runtime functionality that makes VB easier to use, then why not simply switch to C# now and be done with it. Does anyone doubt that Microsoft wants the whole world to be using C# exclusively? I'm fairly sure that it's their strong preference.

Quote:

---

Originally Posted by RobDog888

This is how I feel also. I just cant bring myself to use the MS.VB namespace because it just doesnt seem to be
a good practice to keep writting "old" code. Heck what if we had a BASIC namespace because MS provided forward
compatibility across the 6 versions of VB. Would you write code using the BASIC namespace if it had the smae scenerio
as MS.VB? I think not because you would make a unconscience decision that it is best if you take advantage of the newer
technology because you dont know what the future would be for the "next" version. ;)

---

Sorry if I misjudge anyone, but I think that, like me, many others have convinced themselves that "VB6" code looks ugly and ".NET" code looks good. Go on, tell me it ain't so. When I see a call to MsgBox I cringe inwardly, while a call to MessageBox.Show just looks right. This is all just prejudice and conditioning, though. There was a function in VB6 named MsgBox. There is also a function in the VB.NET Runtime named MsgBox. The two have the same name and essentially the same purpose and result, but they are NOT the same function. Calling MsgBox in VB.NET is not "writing old code" because VB6 code does not compile in VB.NET. The VB.NET version of MsgBox actually calls MessageBox.Show, so it seems to be a little different to the VB6 implementation, which I'm pretty sure didn't. This is just an example and I will not, nor do I suggest anyone else does, start using MsgBox instead of MessageBox.Show. If one calls the other anyway then what's the point? This is not the case for all Runtime functions though, like the example of Len that I used earlier.

The crux of my argument is this: always use the "best" solution for the problem, whatever "best" may mean in any particular case. Learn as much about the VB.NET language as you can and use the most appropriate methods available. Don't call MsgBox when it is just going to call MessageBox.Show anyway, but feel free to use IsDate while there exists no equally simple way to accomplish the same task using System methods. If maximum code portability is your concern then no language-specific feature is any better than another. Don't use CType in VB and C-style casting in C#, but rather the Convert class in both. Above all, noone should consider themselves or anyone else to be wrong for using the VB.NET Runtime.

Now here's something that, I'm sure, will cause a few people's lunches to levitate. One of the primary arguments for not using the Microsoft.VisualBasic namespace has always been the fact that the functions it contains are not available to C#, etc. Well, it occurred to me that Microsoft.VisualBasic.dll is a .NET assembly like any other, so is that really the case? Read it and weep, baby!

Ok...well done. Have a scooby snack.

Wasn't the Microsoft.VisualBasic runtime added into .NET after VB6 programmers whinged like little babies about functions etc? I am sure it was.
So it was added in to shut up 1/2 the VB6 user base.

Woka

Quote:

---

Originally Posted by Wokawidget

Ok...well done. Have a scooby snack.

Wasn't the Microsoft.VisualBasic runtime added into .NET after VB6 programmers whinged like little babies about functions etc? I am sure it was.
So it was added in to shut up 1/2 the VB6 user base.

Woka

---

Even if that is the case, how is that any different to any developer writing their own library of convenient methods?

Hmmmm...I don't think it is any different at all.
One of my main objections to VB.NET is the fact that there are many ways to do the same thing, ie converting a string to an integer.
I don't want to be given 5 ways and told to pick one as there's not much difference. I want one method. Having many methods, which do the same thing, just complicates things and confuses developers.
I still think it's "better" practive not to use VB6 functions at all. Just for consistancy and coding standards etc. Plus I see it as something MS whipped up to please 50% of the users.

I personally don't look down at people who don't use the system namespace, but it does make me think how much .NET do they know. Ie if they've never wandered and browsed the system namespace, then they are not going to be that familiar with it, it's a petty argument, but it does have some truth to it.

Woof

I just spent 10 minutes writing a bloody post to this and IE crashes as soon as i hit the blasted submit button...


IE sucks but not as much as the Visual Basic namespace. Its not OOP and it should not be used. The End.


(my first version was much longer, and more eloquent)

Quote:

---

Originally Posted by jmcilhinney

I've trained myself to use System methods, so I know what you mean by:but if you remove all bigotry and bias, how can that seriously be true? The article also says that the Len() function actually calls String.Length anyway, but it simply does things like check for a null reference first, which your code should do if it's written properly. So tell me, which is neater? This:

VB Code:

Dim myInt As Integer
 
If myString Is Nothing Then
    myInt = 0
Else
    myInt = myString.Length
End If

or this

VB Code:

Dim myString As Integer = Len(myString)

---

Yes, but if you'll be performing multiply operations on or with myString then your argument is blown from out the wet blue stuff.

greetings

Len() is not attached to anything, it is a free floating function and should be treated with the contempt that it deserves.

String.Length is part of the string class and as such is well placed and logical, its insane to have loads of tiny little functions scattered around a language without any structure to them.

Len() is misleading, if the string is null then Len() returns zero. But null is not the same as a zero length string. Anyway Len is not just specific to strings, it takes objects too. It is a throwback from a lesser language.

String.Length() and Len() are simply not comparable.

Quote:

---

Originally Posted by wossname

Len() is not attached to anything, it is a free floating function and should be treated with the contempt that it deserves.

---

What the... ? What exactly is a free floating function? You mean like CType and DirectCast? These functions are part of the VB.NET language itself, so they are "not attached to anything". For your information, the Len function is actually the Microsoft.VisualBasic.Strings.Len function. Microsoft.VisualBasic.Strings is a module in the Microsoft.VisualBasic namespace, and the Len function is a member of that module. Before you go rushing to your keyboard to point out that modules are not OO either, you should read the part in that article about the fact that modules are actually implemented as classes that are declared NotInheritable with all members declared as Shared. It also says that the Len function returns String.Length when the object passed is a String, so please point to the bit that isn't OO.

I am still failing to see what benefits using VisualBasic namespace would give me.
Everything can be done in .NET without the use of this namespace...so why not do it that way? Why cling onto commands that were only implemented to aid the upgrade process from VB6 to .NET???

As for using VisualBasic in C#...Hmmm, would you actually consider this good practise?! I wouldn't.

Woka

Quote:

---

Originally Posted by Wokawidget

I am still failing to see what benefits using VisualBasic namespace would give me.
Everything can be done in .NET without the use of this namespace...so why not do it that way? Why cling onto commands that were only implemented to aid the upgrade process from VB6 to .NET???

As for using VisualBasic in C#...Hmmm, would you actually consider this good practise?! I wouldn't.

Woka

---

Personally, I wouldn't use much from the VB Runtime, but IsDate springs to mind immediately as being useful. Given that I'm well aware of the implications, I'd use IIf in certain situations as well (I can hear the groans from here, only certain situations I said). There is also the DateDiff function that could be useful in certain circumstances where DateTime and TimeSpan would take several lines to do the same thing. These are just a few examples and I haven't really explored the namespace. I'm sure there are many useful functions in there. We write our own functions and libraries all the time. Why do some consider these inherently inferior?

As for using VB in C#, I've created libraries in VB and referenced them in C# before, and vice versa. What's the difference? I'm not saying that I would necessarily do it, but you aren't providing a compelling reason not to.

...reason is beacuse it's legacy code only added when .NET 1st came out many years ago so it would keep VB6 developers happy. That's one main reason.

Now I am picking hairs, but your DateDiif example was not a good one to use:

VB Code:

Dim Span As New TimeSpan(ToDate.Ticks - FromDate.Ticks)

Is WAYYYY better than:

VB Code:

Dim lngHours As Long
   lngHours = DateFiff("h", dteTo, dteFrom)

Wooooof

Quote:

---

Originally Posted by BadgerBoy

I personally don't look down at people who don't use the system namespace, but it does make me think how much .NET do they know. Ie if they've never wandered and browsed the system namespace, then they are not going to be that familiar with it, it's a petty argument, but it does have some truth to it.

Woof

---

Ruff! :thumb:

Quote:

---

Originally Posted by Wokawidget

...reason is beacuse it's legacy code only added when .NET 1st came out many years ago so it would keep VB6 developers happy. That's one main reason.

Now I am picking hairs, but your DateDiif example was not a good one to use:

VB Code:

Dim Span As New TimeSpan(ToDate.Ticks - FromDate.Ticks)

Is WAYYYY better than:

VB Code:

Dim lngHours As Long
   lngHours = DateFiff("h", dteTo, dteFrom)

Wooooof

---

First of all, the functions in Microsoft.VisualBasic are NOT legacy code. They have the same names as functions that existed in VB6 and they have essentially the same result as those functions, but they are NOT those functions. The Microsoft.VisualBasic namespace and its members are FULLY implemented using VB.NET. I could write this function for my own convenience:

VB Code:

Public Function IsDate(ByVal expression As Object) As Boolean
        Try
            Dim temp As Date = Convert.ToDateTime(expression)
            Return True
        Catch ex As Exception
            Return False
        End Try
    End Function

Same name, same result, but written using VB.NET so not legacy code. Same goes for Microsoft.VisualBasic.DateAndTime.IsDate. Same name, same result, but written using VB.NET so not legacy code. I'll bet the implementation is way better than mine too.

Secondly, I think my DateDiff example is a very good one. Certainly the TimeSpan option is the better in many circumstances, but if you read the help topic for DateDiff you'll see that it is very flexible. I'm not prepared to try right now (1.24 AM), but given the many options it provides, I bet I could find quite a few things that DateDiff could do in fewer lines of code than using DateTimes and TimeSpans could.

Quote:

---

Originally Posted by BadgerBoy

I personally don't look down at people who don't use the system namespace, but it does make me think how much .NET do they know. Ie if they've never wandered and browsed the system namespace, then they are not going to be that familiar with it, it's a petty argument, but it does have some truth to it.

---

Absolutely. I agree that all VB.NET developers should explore as much as possible, but exporing the Microsoft.VisualBasic namespace might not be a bad idea for some as well. Why reinvent the wheel or write more code than is necessary if a solution already exists? As I've said before, I will use a System function over a VB Runtime "equivalent" any day, but if there is no System function or the System-based solution is more complex, I'm sticking with MS.VB.