How To Prepare Yourself For Moving From VB6 To VB.NET

How To Prepare Yourself For Moving From VB6 To VB.NET

In this article, I will make a few guesses of how you canchange your coding style and prepare yourself already today for the transition,to make it as smooth as possible. In the article I will focus on components,especially for the server-side.

Moving from VB6 to VB.NET doesn’t seem tobe a small step. Still, we will do the transition in the future because of moreimprovements than I had dared to hope for. Probably, you won’t port all yourcode day one and a lot of your code will probably benefit much more from arewrite rather than a port. Anyway, perhaps you like to start to prepareyourself as early as possible.

Beta 1 has been outfor a while, but what I write in this article is actually just guesses.In the history there have been several guesses that we are laughing at today.One example of such a guess (at the time it was created I don’t think they sawit as a guess) was something like “the world will not need more than fivecomputers for all the computations in the future”. Another one was somethinglike “a PC will never need more than 640 KB of RAM”. Hopefully my guesses willnot be that funny in the future. In a year or so we’ll know.


I’m notgoing to spend a lot of time describing what VB.NET is. I’d just like to give ashort intro to it before the real article starts.

As youprobably know by now, Microsoft is upgrading all its Visual Studio (VS)languages right now. One example of that is that VB6 will be changed to VB.NET.At first you will benefit from several techniques that are shared between allthe VS languages such as a new ADO.NET, ASP.NET, WinForms,WebForms, Web Services and the .NET Framework (that is a rich class librarywith a lot of functionality). You will also find a new Integrated DevelopmentEnvironment (IDE) and a new debugger. Both are to be used for all the .NETlanguages.

VB.NETwill be a full-fledged .NET-language and because of that it can use all thejust mentioned functionality, plus a whole lot more. Old problems with VB willbe gone such as only the single threaded apartment-model (STA) formulti-threading and VB.NET will also be a much more object-oriented languagethan before. The latter you will find in the shape of for exampleimplementation inheritance, class methods and the possibility to sendparameters to constructors. You will finally have structured error handling andthe possibility to force explicit cast and to force declaration of datatypesfor variables. Not a single day too early, right?

Thecode you write in VB will be compiled to Intermediate Language (IL). The ILwill then be executed with the Common Language Runtime (CLR) (after it has beencompiled to machine code). That is exactly what is happening with C# too forexample and both those languages (and the rest of the .NET-languages) willprobably have more or less the same performance characteristics. (It dependsupon how efficient IL they will generate.)


There is a lot of informationavailable already about VB.NET and also information about how to upgrade. Acommon tip is to be as explicitas possible in your code. An example of that is to write out both ByRef and ByVal in your parameter lists even though you will get the effect from ByRef if you don’t say anything else. The reasonfor this is almost to be called well known by now. In VB.NET, ByVal will be used if nothing else has beenstated. So, it’s effectively the opposite from VB6. The upgrade wizard willhopefully take care of this well, but if you will need to directly change habitwhen you jump between VB6 and VB.NET projects (which most of us will have to dofor a long time) it’s probably a very good idea to use this tip.

Fromnow on in this article, I will not mention tips that I’ve read anywhere else sothe rest will be my own guesses that I will have to be embarrassed for myselfif they prove wrong.


Justone more thing before we get going. Will it be important to rush to upgradeyour VB6 components to VB.NET components? As I see it, it will not. I will mostprobably let my components that are in production when VB.NET ships, stay inVB6 for a while (or perhaps for a very long time). The interoperabilityseems to be strong and therefore it will probably be perfectly alright to letyour old VB6 components cooperate with new ones that you definitely (hmmm,should be perhaps) will rush to create in VB.NET. (Please note though thatthe interoperability layer will decrease performance slightly.)

Anexception to this is if you have COM+ components that really would benefit alot from those COM+ component services that you can’t use today such as objectpooling. Anyway in most cases you don’t have to rush to the upgrading process.Even if that is the case, why not prepare yourself for the eventual upgrade?So, let’s take a look at what I think should be done today.


Sometimesyou hear that VB6 isn’t good for reusing code because you don’t haveimplementation inheritance. In my opinion implementation inheritance is justone of several mechanisms for reusing code. You can of course use ordinary codemodules for that, but also put code to share in class modules that youinstantiate from several other classes.

Several of you might think that codemodules are a bit retro, but I use them quite a bit for highly centralized codesnippets in my COM+ components. I have had stability problems earlier withother solutions for those snippets and therefore I use code modules and I willleave it that way until VB.NET. In VB.NET I will get more or less the samebehavior with class methods (and I can continue to use code modules too if Iwant).

Sayingthat you should centralize and reuse code instead of using copy and paste isprobably nothing new for you. Still I think that it can be taken even furtherin most applications that I’ve looked behind the surface of. (That goes forthose I’ve written myself too.) If you have a code snippet at one place only, thenit’s as easy as it can be to upgrade that one to a new approach. OK, usingsearch and replace is quite effective too, but you will always have the risk ofmissing something!

If youfind that copy and paste has been used too much in VB components, the situationis often much worse when it comes to stored procedures and ASP code. (At leastfor the code I’ve seen. Ehrm… And also that I’ve written a long time agoin the past.) This is out of the scope for this article, but since I gotexcited, I couldn’t help myself for adding this paragraph.


Ipromised that I would only write about my own tips and not duplicate what I’veread from others. One thing about VB.NET that you perhaps have heard fromseveral places is that an Integer in VB6 will be a Short in VB.NET and that a Long in VB6 will be an Integer in VB.NET. I will not say that once again.

What Iwill say is that I think it can be wise to change your naming conventions todayif you prefix your variables to describe the datatype. I used to use int and lng as the prefix in VB6 to describe Integer and Long, but I’ve started to use sht and int instead. Since I’ve used my old prefixes for eight years orsomething like that, it will take some time to kill the old habit.

Skip theflaming e-mails please. I’m aware of that not everybody thinks type prefixesshould be used. I like them and I will continue to use them in the future.Since I’m changing my mind quite often, I will probably skip using them aftereight years or so.


Gamma,Helm, Johnson, Vlissides had their best selling book Design Patterns releasedin 1995. It’s still a bestseller after all those years. How come? (I guess thecomputer industry is one of the rare that think of five years as all thoseyears.)

Proposalsfor how to design applications never goes out of fashion, right? As a matter offact I think it will be important to be more design-centric than what is commonfor the average VB6 programmer today. I think that is very good since I havebeen nagging about that for years. (If you say something often enough, itfinally becomes true, right?)

If Itry to be serious for a while, I would really like to stress the tip to readGamma’s book


It tookme a long time to start enjoying user-defined interfaces, but after a couple ofminutes I saw the light. Ever since then, I’ve been using them a lot anddefinitely think I’ve benefited a lot from them.

I don’tknow if it’s because of my instinct for adjusting myself or something else, butthe last few years I haven’t missed implementation inheritance much and that ismostly because of VB’s support for separating the interfaces from theirimplementation by using user-defined interfaces.

At oneperiod in time, I thought that Microsoft told us about the problems withimplementation inheritance in large real world applications because they didn’thave the support for it in COM and VB. Then I read Szyperski’s book ComponentSoftware. Beyond Object-Oriented Programming and understood that the problemswere well-known in the academic research since a long time back.

Yes, Iknow that we will have implementation inheritance in VB.NET, and I willdefinitely use it. (As I understand it, Microsoft has at least partly solvedsome of the classical problems with implementation inheritance.) I also knowthat I will definitely use user-defined interfaces a lot in the future too.Since VB.NET won’t have support for multiple inheritance, you will give addedsupport to classes by implementing interfaces. You will also use user-definedinterfaces in situations similar to when you use them today.

BTW,Microsoft has also refined the support quite a bit for user-defined interfacesin VB.NET, but that is another story.


FinallyVB.NET will have support for structured error handling with Try, Catch and Finally! In the Try-block you write the ordinary code, in the Catch-block you take care of errors and in the Finally-block you have code that you want to beexecuted no matter if there is an error or not.

Eventhough the error handling in VB6 is quite primitive you can get close to thesemantics of Try, Catch and Finally and by doing that you will geta solid structure for the methods in your components already today.

In thearticle Exampleof code structure for COM+ component I describe a code structure for acomplete COM+ component, but most of the attention is being paid to the errortrapping and how to simulate Try, Catch and Finally.


COM+Component Services is dead! Long live .NET Component Services! What I’m sayingis that the COM+ programming model that you’ve come to love, seem to be more orless exactly the same with .NET. (The rumor says that the way to use .NETComponent Services will change a bit in beta 2, but that is as far as I knowtoday just rumors.)

As aVB-programmer you will with VB.NET get access to more component services thanbefore so it will just be more fun tomorrow. I’m sure you will enjoy COM+Component Services today also (and also see a lot of benefits in using them) somy recommendation is clear. Get accustomed to them and use them if you haven’tyet!


Hopefully this article has added a wholebunch of tips to your collection of information for how you can prepareyourself but also your VB6 components already today for upgrading to VB.NET.The more design-aware you are and the more well-designed your VB6 componentsare, the more possible it will be to port you and your components to VB.NET. Thatis my summarized guess!



About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist