MSDN Article on IsDate and Legacy Code (saying it's not bad)

[JDYoder]

Afraits had found a snippet from MSDN about IsDate, which I appreciated. When I went searching for the entire article, I found it here...

 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchmicrosoftvisualbasicnetinternals.asp

 

However, I basically want to highlight these four paragraphs...

 

Visual Basic developers have long associated the term "Visual Basic Runtime" with a set of core library files, such as msvbvm60.dll, that are required for Visual Basic 6.0 (and prior) programs to run. In Visual Basic .NET, the term "Visual Basic Runtime" refers to the set of classes in the Microsoft.VisualBasic namespace. 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.

 

Many of the methods in the Visual Basic Runtime actually use methods and properties from the System namespace (for example, Len() returns String.Length). In some cases you can achieve equivalent results by accessing .NET Framework class library classes directly, but typically you will be more productive using the Visual Basic Runtime when authoring your code. In many cases the Visual Basic Runtime wrappers provide additional functionality that you would have to code yourself if using the System namespace directly. In other cases, such as IsDate, there is no directly equivalent functionality in the System namespace.

 

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

 

As the rest of this section will illustrate, avoiding the Visual Basic Runtime for performance reasons is generally unnecessary and the extra effort is likely to impede productivity, particularly for programmers with a Visual Basic 6 background.

 

 

I'm particularly interested in that last paragraph and would like some discussion since this seems to be the opposite of what everyone here has been telling me about the VB6 legacy code. So do you disagree with this MSDN claim? Is this article out-of-date with current MSDN policy? (It's two years old.) I ask because I'm finding that last paragraph to be very true. Not that I mind learning the newer techniques, but if it doesn't matter in the end, then what's your arguments against the VB6 legacy code?

 

FYI, I really am interested in people's thoughts. Meaning, I'm not just bringing this up to be difficult.

[Iceplug]

I've probably known this for about 4 months now... I still use System namespace coding since I prefer to know exactly what kind of code that I'd be doing in other .NET languages such as C# and J#. The key with me is more basis on cross-language support... .

Now, IsDate() is nice and all in VB.NET, but until I know how to do it in C# and J# (DateTime.Parse in a try block?), I avoid it.

 

It's a catch-22 in my book: Would you like to program VB.NET with emphasis on VB, or with emphasis on .NET?

[jmcilhinney]

I agree with Iceplug and would also like to add that, no matter what Microsoft may say, there is no guarantee that support for these VB6-style functions will continue into the future. I don't think many people would disagree that Microsoft would like VB6 to disappear altogether. They realise that this is not going to happen immediately, though, so they have provided the support for now. I've no doubt that additonal functionality will appear in the System namespaces in future and, at some point, much of the functionality in Microsoft.VisualBasic will be phased out. Microsoft want the world to use C# and there's nothing like those old VB6 functions in C#, so I believe that Microsoft don't really want people to use them in the long run.

[jmcilhinney]

I have read a good portion of that article you mentioned, JDYoder, and it does make for interesting reading. I do stand by my previous post, but I may be less vehement in my condemnation of methods from Microsoft.VisualBasic in the future. I apologise if any of my previous comments have appeared harsh. In fact, I apologise even if they didn't appear so, because I guess they were intended to be at least a little bit harsh. :o

[Afraits]

PLus a someone in the old thread pointed out that framework V2 has a DateTime.TryParse implies that Microsoft have listened to developer comments and provided further .NET equivalents that move away from the use of the VisualBasic namespace

[JDYoder]

I have read a good portion of that article you mentioned' date=' JDYoder, and it does make for interesting reading. I do stand by my previous post, but I may be less vehement in my condemnation of methods from Microsoft.VisualBasic in the future. I apologise if any of my previous comments have appeared harsh. In fact, I apologise even if they didn't appear so, because I guess they were intended to be at least a little bit harsh. :o[/quote']

 

Ah, don't worry about that. I'll take a passionate programmer over one who just fumbles in the dark any day. :)

 

 

 

 

PLus a someone in the old thread pointed out that framework V2 has a DateTime.TryParse implies that Microsoft have listened to developer comments and provided further .NET equivalents that move away from the use of the VisualBasic namespace

 

Cool.

[jmcilhinney]

Ah' date=' don't worry about that. I'll take a passionate programmer over one who just fumbles in the dark any day. :)[/quote']Your graciouness is appreciated. You may be interested to know that I've sparked a rather lively debate on another forum by quoting that article. It was influence by the residents there that helped hone my aversion to alleged "legacy code". I've come to realise that the "pure .NET" label that many people like to use, and I myself have on many occasions, is rooted in elitism and is just a way for VB.NET developers to feel like they've evolved into something greater than a mere VB6 developer. I'm still going to use System functions where available, but I will view the VB Runtime as a legitimate, and occasionally preferable, alternative.

[JDYoder]

Now I'd like to praise the wonderful features and unrated functionality of GW-Basic, which has too long been swept under the rug, belittled, and scoffed at by VB6 programmers for not being powerful enough... ;)

 

Seriously, it's cool you sparked a debate. For introverted programmers, we really speak out when we start talking technique, don't we?

[mutant]

For me it all comes down to interoperability between languages and knowing excatly what happens in the code. How does using the "native" .NET methods over the legacy ones impede the productivity? Were they really that big and complicated that you could not replace it very few .NET calls? I can't really answer that question since my experience with VB6 was short, and lets just say not pleasant :), but I think you get my idea. As for interoperability, there just has to be some standard, and Microsoft should not encourage deviating from it. Since .NET gives us a beautiful way to combine languages, multiple people working with different sets of methods and coming from different language background, may cause confusion to one another. But on the other hand, if they stuck to using the regular methods, everybody is happy, and noone has to research additional methods while trying to maintain or change the other person's code.

I personally don't think many people just use the regular .NET methods just to show how they have evolved over VB6 specifically. Programming has to evolve in general, and if it means I have to write two lines of code instead of one on rare occassions, I'll do it. The evolution over VB6 did happen though, and that cannot be denied, but it brought so many good things with it that I don't know how somebody could go back :).

Edited July 14, 2005 by mutant

[FZelle]

I'm doing consulting jobs, helping companies move from vb6 to vb.net.

 

What I see is that those that from the beginning avoid the legacy stuff,

procede alot faster, because they use the new stuff and the new technologie.

 

Those that stay with the legacy stuff, struggle more often, because they also

stay in the old non oop stinking.

 

Otherwise use everything you can to produce save working code.

 

The less easy readable lines your software has the better it will work.

[JDYoder]

How does using the "native" .NET methods over the legacy ones impede the productivity? Were they really that big and complicated that you could not replace it very few .NET calls?

 

Not sure if you meant for these questions to be rhetorical or not, but as the MSDN article indicated, I think it has to do more with some functions that can't be easily replicated in .NET that existed in VB6, such as DateDiff, which for me to rewrite on my own (completely to go beyond days) would be quite extensive.

 

One should definitely learn the trappings of .NET and what it's capable of, but I think what some are describing (in relation to programmers who code with a grasp of the .NET methodology as opposed to that used in VB6) has more to do with the overall structure (datasets, data adapters, inheritance, overloading, etc) than individual one line commands offered by the Microsoft.VisualBasic namespace.

 

Good thoughts on everyone's part.

[Robby]

You all made some good points but one thing that may have been missed:

Using some of those legacy functions may impede performance not weather or not the Microsoft.VisualBasic is included in your assembly.

[jmcilhinney]

You all made some good points but one thing that may have been missed:

Using some of those legacy functions may impede performance not weather or not the Microsoft.VisualBasic is included in your assembly.

Had you read the article, you would know that Microsoft.VisualBasic does not get "included in your assembly". It is part of the .NET Framework, so it is there regardless, and using it is no more or less expensive than using any other .NET Framework library.

 

One of the most common reasons I've seen quoted for not using methods from the VB Runtime is they are not available to C#, et al. Think again! Microsoft.VisualBasic.dll is a .NET assembly like any other, so you can reference it in a C# project and use the methods it provides. If you don't believe me then try it for yourself. I'm not necessarily saying that C# developers should start doing this. What I am saying is that, while it may seem strange to reference the VB Runtime in C#, it is no more or less legitimate than referencing any other library written in VB.NET. One of the main aims and advantages of .NET is interoperability between assemblies written in different languages. It's more often done the other way around, i.e. referencing an assembly that was written in C# in a VB.NET project, but by the time your code is compiled to IL, noone cares what language it was written in anyway.

[Robby]

It seems I didn't explain myself very well, although you're right in that I didn't read the entire article, the point I was trying to make was that using the legacy functions is expensive not referencing the libraries.

[jmcilhinney]

Generally speaking, the only expense associated with these "legacy" functions is actually making the one extra function call, which will create no perceptible difference in performance in the vast majority of cases. I do agree that there is no point making the extra function call if it serves no useful purpose, e.g. MsgBox and MessageBox.Show, but there are also cases where the Runtime function call provides additional functionality. All the VB Runtime functions are implemented using VB.NET, so there is no reason you couldn't provide this functionality yourself, but why reinvent the wheel. As always, use the best solution for the problem, which may well be a VB Runtime function in some cases.