Home/ Questions/Q 69695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T19:36:52+00:00

I’m preparing a class on Visual Basic 2005 targeting Visual Basic 6 programmers migrating

  • 0

I’m preparing a class on Visual Basic 2005 targeting Visual Basic 6 programmers migrating to the .NET platform.

My primary concern is to teach my students the best practices for developing in .NET, and I am wondering about whether to consider the use of the VB runtime functions VB.NET legitimate or not.

I have read that many of the VB functions in VB.NET actually invoke methods on the .NET Framework, so it appears they exist primarily to ease the transition from earlier versions of Visual Basic to VB.NET. However, the VB.NET team seems to recommend to use them whenvever possible since they claim they put some optimizations in there on top of the .NET framework APIs.

What’s your take on this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

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

    • 0