Microsoft.VisualBasic vs System

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.