VB runtime functions in VB.NET for VB6 programmers [closed]

Answer 1

There's already a lot for VB6 programmers to learn in moving to VB.NET. Why not let them use the VB functions at first, but do teach them the .NET framework versions. Later they could switch to the .NET framework functions, particularly if they are likely to need to use C# too.

EDIT (much later): two renowned VB gurus take opposing views!

• Francesco Balena (in his popular book Programming Microsoft Visual Basic 2005: The Language) recommends ex-VB6 developers learn the .NET syntax as soon as they feel comfortable with the new language and avoid using methods and classes in Microsoft.VisualBasic namespace if possible [p. 100]. His point is that in general native .NET methods offer better flexibility and learning them is an investment in case you later need to use C# or another .NET language.
• Dan Appleman (in his popular book Moving to VB.NET: Strategies, Concepts, and Code) recommends you feel free to stick with the native Microsoft.VisualBasic namespace avoiding only those in the Microsoft.VisualBasic.Compatibility.VB6 namespace [p. 265]. His point is that Microsoft.VisualBasic is a core part of the .NET framework.

Answer 2

Where I'm at, I have to move back and forth between C# and VB.Net frequently. With that in mind, we really don't like the old VB functions, especially the strings functions: Trim(), Replace(), Len(), UCase(), etc. They just look odd in a .Net program, and I wouldn't want to see them in code I had to work on.

The only exception there might be Len(), if you read code in your head using the of verbage. In that case, reading Len(theString) as length of theString seems to make sense. In the others, it's more of an operation performed by the string, and so I want to see the . (dot) notation.

On the other hand, I've had a hard time weaning myself from the conversion operators: CStr, CInt, CDbl, etc.

I can't tell you why I like one type and not the other; it could just be that I find Convert.To___() too verbose, or maybe it has something to do with them being operators rather than functions.

Edit
This point kinda got lost in the rest of my post, so I want to emphasize it again:

In a lot of places, VB.Net co-exists with C#. I don't think you see as many VB.Net-only shops as you might for C#. It's just not as popular, and a lot of the VB.Net shops move to VB.Net just as a transition state while the programmers also learn C#. In these mixed environments, it's makes a lot of sense if the old VB functions are strictly forbidden in new code. You never know when a module will need to be moved over, and there is some mind-share overhead in having to be able to grok both styles at once. So it's really a bad idea not to understand both.

Answer 3

If you want to teach .Net framework best practices that can be moved back and forth between the languages, I would suggest removing the global import for Microsoft.VisualBasic. This essentially forces you to do a Microsoft.VisualBasic.Trim() etc.. instead of just "Trim()".

If I am not mistaken, in Visual Studio 2008 you now have the ability to remove the reference all together for "pure" .Net mode in vb.net, which makes it easier to move back and forth between languages.

If you are just teaching vb.net guys, like the above posters mentioned, use them, as they are available and require less typing.

Answer 4

Well, I guess you have to take them at face value. I am a C# programmer primarily, but have been working on a VB.NET web application for the last 6-8 weeks.

My seat of the pants estimation suggests that using conversion functions such as CInt, CDate etc to be as fast as using Convert.Toxxx methods.

My advice would be: if it makes it easier, and it doesn't have a performance penalty then go for it! I would also teach them the .NET approach as well and let the user decide.

BTW, as a C# guy, I love the ease of the Cxxx routines. Just because they are only available in VB.NET doesn't mean you shouldn't use them (IMHO). Horses for courses and all that.

Answer 5

One thing that you should probably mention if you're mentioning both the framework methods and the VB.NET functions is that although they sometimes feel like they're the same, they can actually do subtly different things.

For example, the equals operator for strings treats a null string as the same as String.Empty (see The real cost of performance for an example of what happens when you forget!)

Also, the VB.NET functions often give a good default setting for doing the operation in question, but where you need more control, it will quite often be necessary to go back to the Framework methods - for example, if you need to make string conversions in a different culture.

Answer 6

If you're teaching VB, those functions are part of VB. If you're teaching the .Net Framework, those functions aren't part of the Framework. If you're trying to get your work done and you have tools available, use your tools.