Marine Corps Leadership Secrets - Part VString Class vs. Microsoft.VisualBasic Namespace - Part I

10 Things to Avoid When Moving From VB6 to VB.NET

August 7th, 2007

trashcanI was looking at some code today that different people had posted on a VB.NET related forum and noticed that their code was very VB6-centric. There is certainly a temptation to keep things familiar when moving from VB6 to VB.NET. Microsoft intentionally makes this easy to do. However, it often isn’t the best way to do things. In this article, we’ll take a look at 10 of the major methods and techniques to avoid during your transition.

1. File System Object

This object gained some popularity when VB6 began supporting it because it made it easy to do a number of file related functions without having to resort to using Windows API calls. Its performance wasn’t that great but it was easy to use and thus it ended up in a lot of VB6 programs. Now, in VB.NET, all of these file functions are replaced by System.IO and My.Computer.FileSystem functions. Use these functions instead in order to get better performance and more functionality.

2. Unnecessary Windows API Calls

Sure, some Windows API calls are still needed from time to time in the .NET world. However, many things that required API calls in VB6 are entirely within the .NET Framework. For example, to get the current version of Windows in VB6 you would have needed to use an API based function like mine. However, in VB.NET, all you need is this:


Even more complex operations like alternating colors in a Listbox can be done .NET without resorting to API calls. The bottom line is to review any API calls that you’re considering in your VB.NET application and make sure that there are no equivalent Framework methods you can use instead.

3. Microsoft.VisualBasic.Compatibility.VB6 Namespace

This namespace contains legacy support for old VB6 controls, like the File Listbox control, and old ADO data constructs. While this namespace can be useful when doing a gradual transition of a legacy app, it should be avoided completely in any new VB.NET application you build.

Note, however, that this is different from the main Microsoft.VisualBasic. This namespace also has some legacy functions but it also contains many new and useful functions as well. For this namespace, you should evaluate them on a case-by-case basis just like I did in my series on the My.Computer.FileSystem functions. Don’t make the mistake of throwing the baby out with the bathwater when it comes to this namespace. That said, there are some parts of this namespace that I think you should avoid as you’ll see below.

4. VBMath Random Methods

You should use the .NET Random techniques instead.

5. MsgBox

It’s generally considered better to use the MessageBox.Show method because, with its 20 overloads, is much more flexible and readable than this legacy method.

6. SaveSetting and DeleteSetting

Unless you’re having to read legacy data stored in these registry locations, it is a much better idea to use the .NET way of doing things in an application config file. This avoids the registry, which can be problematic, and helps insure better .NET compatibility.

7. CallByName

This was a little used, but powerful, method in VB6. In .NET, you should use delegation instead for the best results.

8. FileSystem

There are actually two FileSystem classes in the Microsoft.VisualBasic. One is in the My.Computer namespace while the other, which is in the main namespace, supports legacy VB file operations like Get and Put. I strongly recommend avoiding these functions unless you have legacy data files you need to read. Instead, consider using the .NET stream classes, file functions provided in the My.Computer.FileSystem namespace, or serialization.

9. ErrObject

Instead of this legacy method, use the Try…Catch method of dealing with exceptions. Also, take a look at the ability to trap unhandled exceptions at the application level using the application events framework.

10. Collection Object

In place of the old Collection class, consider using the new type-safe generic List classes in your new programs. They’re much more flexible and you can specify the type of object the list holds.

That covers my top 10 items to avoid. Do you agree or disagree? Do you have some you would like to add to the list? If so, please leave a comment.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: VB6 To VB.NET

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (4 votes, average: 5 out of 5)
Loading ... Loading ...

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities