Overview
Moving from VB6 to VB.NET doesn't seem to be a small step. Still, we will do the transition in the future because of more improvements than I had dared to hope for. Probably, you won't port all your code day one and a lot of your code will probably benefit much more from a rewrite rather than a port. Anyway, perhaps you like to start to prepare yourself as early as possible. so Beta 1 has been out for 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 saw it as a guess) was something like "the world will not need more than five computers for all the computations in the future". Another one was something like "a PC will never need more than 640 KB of RAM". Hopefully my guesses will not be that funny in the future. In a year or so we'll know.

A SHORT INTRO TO VB.NET
I'm not going to spend a lot of time describing what VB.NET is. I'd just like to give a short intro to it before the real article starts.
As you probably 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 all the VS languages such as a new ADO.NET, ASP.NET, WinForms, WebForms, Web Services and the .NET Framework (that is a rich class library with a lot of functionality). You will also find a new Integrated Development Environment (IDE) and a new debugger. Both are to be used for all the .NET languages.
VB.NET will be a full-fledged .NET-language and because of that it can use all the just mentioned functionality, plus a whole lot more. Old problems with VB will be gone such as only the single threaded apartment-model (STA) for multi-threading and VB.NET will also be a much more object-oriented language than before. The latter you will find in the shape of for example implementation inheritance, class methods and the possibility to send parameters to constructors. You will finally have structured error handling and the possibility to force explicit cast and to force declaration of datatypes for variables. Not a single day too early, right?
The code you write in VB will be "compiled" to Intermediate Language (IL). The IL will then be executed with the Common Language Runtime (CLR) (after it has been compiled to machine code). That is exactly what is happening with C# too for example and both those languages (and the rest of the .NET-languages) will probably have more or less the same performance characteristics. (It depends upon how efficient IL they will generate.)

AVAILABLE INFORMATION
There is a lot of information available already about VB.NET and also information about how to upgrade. A common tip is to be as explicit as 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 reason for this is almost to be called "well known" by now. In VB.NET, ByVal will be used if nothing else has been stated. So, it's effectively the opposite from VB6. The upgrade wizard will hopefully take care of this well, but if you will need to directly change habit when you jump between VB6 and VB.NET projects (which most of us will have to do for a long time) it's probably a very good idea to use this tip.
This fact and a couple of others about why to be more explicit could be found in VB-2-The-Max email (weekly newsletter ) about VB.NET. and also in Billy Hollis' article http://www.vbpj.com/upload/free/features/vbpj/2000/12dec00/bh0012/default.asp.
From now on in this article, I will not mention tips that I've read anywhere else so the rest will be my own guesses that I will have to be embarrassed for myself if they prove wrong.

RUSH TO UPGRADE?
Just one more thing before we get going. Will it be important to rush to upgrade your VB6 components to VB.NET components? As I see it, it will not. I will most probably let my components that are in production when VB.NET ships, stay in VB6 for a while (or perhaps for a very long time). The interoperability seems to be strong and therefore it will probably be perfectly alright to let your old VB6 components cooperate with new ones that you definitely (hmmm, should be "perhaps") will rush to create in VB.NET. (Please note though that the interoperability layer will decrease performance slightly.)
An exception to this is if you have COM+ components that really would benefit a lot from those COM+ component services that you can't use today such as object pooling. 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.

CENTRALIZE CODE
Sometimes you hear that VB6 isn't good for reusing code because you don't have implementation inheritance. In my opinion implementation inheritance is just one of several mechanisms for reusing code. You can of course use ordinary code modules for that, but also put code to share in class modules that you instantiate from several other classes. Several of you might think that code modules are a bit retro, but I use them quite a bit for highly centralized code snippets in my COM+ components. I have had stability problems earlier with other solutions for those snippets and therefore I use code modules and I will leave it that way until VB.NET. In VB.NET I will get more or less the same behavior with class methods (and I can continue to use code modules too if I want).
Saying that you should centralize and reuse code instead of using copy and paste is probably nothing new for you. Still I think that it can be taken even further in most applications that I've looked behind the surface of. (That goes for those I've written myself too.) If you have a code snippet at one place only, then it's as easy as it can be to upgrade that one to a new approach. OK, using search and replace is quite effective too, but you will always have the risk of missing something! If you find that copy and paste has been used too much in VB components, the situation is often much worse when it comes to stored procedures and ASP code. (At least for the code I've seen. Ehrm... And also that I've written a long time ago in the past.) This is out of the scope for this article, but since I got excited, I couldn't help myself for adding this paragraph.

CHANGE YOUR NAMING CONVENTIONS
I promised that I would only write about my own tips and not duplicate what I've read from others. One thing about VB.NET that you perhaps have heard from several 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 I will say is that I think it can be wise to change your naming conventions today if 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 or something like that, it will take some time to kill the old habit.
Skip the flaming e-mails please. I'm aware of that not everybody thinks type prefixes should 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 after eight years or so.

READ GAMMA ETC (AGAIN)
Gamma, Helm, Johnson, Vlissides had their best selling book "Design Patterns" released in 1995. It's still a bestseller after all those years. How come? (I guess the computer industry is one of the rare that think of five years as "all those years".)
Proposals for how to design applications never goes out of fashion, right? As a matter of fact I think it will be important to be more design-centric than what is common for the average VB6 programmer today. I think that is very good since I have been nagging about that for years. (If you say something often enough, it finally becomes true, right?)
If I try to be serious for a while, I would really like to stress the tip to read Gamma's book (and read it again if you have read it in the past). Another highly recommended book about design is "Buschmann, Meunier, Rohnert, Sommerlad, Stal: Pattern-Oriented Software Architecture. A System of Patterns". There are of course many more... If you're like me, you love knowledge and skills that last a long time. I started learning SQL at the university and practiced it a lot in my first real-world project 1989. SQL is still usable once in a while. Learning about design, patterns and such has been useful for a while and will continue to be for several years to come.

USE STORED PROCEDURES A LOT
The more I program in VB6, the more I like stored procedures. As a matter of fact, I'm actually a bit serious here. I'm very fond of stored procedures and that fondness is growing all the time. OK, there are drawbacks with using stored procedures such as the portability to other database products, but at least in my case the positive effects are defeating the drawbacks by far.
What does this have to do with VB.NET you ask? Good question! While I'm thinking about an answer to that one I like to give you a couple of examples of typical advantages with stored procedures compared to having all the data access code written in VB6: · Easier performance tuning.
Let's say you find out that you have a performance problem with the code accessing the database, if you find that the problem lies in a stored procedure instead of in your COM+ component you should be happy. It's much more productive to test different theories of how to solve the problem!
· Easy to return several recordsets from one call to the database. That is an efficient way of fetching related information from several tables, that you don't want to fetch in a joined form. You then use .NextRecordset in ADO to get to the different recordsets that you have returned from the stored procedure. · Raw performance.
Using stored procedures is still the most effective way of communicating with the database when it comes to raw performance. I gave a specific example of that in my article at ASPToday called "Comparison of ADO transactions, COM+ Transactions and T-SQL transactions - Part 2". As I said, that was just a couple of examples, but since this article is (or at least should be) about how to prepare for VB.NET, I don't want to get stuck in that discussion. So, why do I push stored procedures in this context? Well, if you have more code in stored procedures and less in VB6 components, the less amount of code you will have to port and as a bonus you have achieved several other benefits too.

CONTINUE TO USE USER-DEFINED INTERFACES
It took me a long time to start enjoying user-defined interfaces, but after a couple of minutes I saw the light. Ever since then, I've been using them a lot and definitely think I've benefited a lot from them. I don't know if it's because of my instinct for adjusting myself or something else, but the last few years I haven't missed implementation inheritance much and that is mostly because of VB's support for separating the interfaces from their implementation by using user-defined interfaces.
At one period in time, I thought that Microsoft told us about the problems with implementation inheritance in large real world applications because they didn't have the support for it in COM and VB. Then I read Szyperski's book "Component Software. Beyond Object-Oriented Programming" and understood that the problems were well-known in the academic research since a long time back.
Yes, I know that we will have implementation inheritance in VB.NET, and I will definitely use it. (As I understand it, Microsoft has at least partly solved some of the classical problems with implementation inheritance.) I also know that 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 added support to classes by implementing interfaces. You will also use user-defined interfaces in situations similar to when you use them today.
BTW, Microsoft has also refined the support quite a bit for user-defined interfaces in VB.NET, but that is another story.

SIMULATE TRY, CATCH, FINALLY
Finally VB.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 be executed no matter if there is an error or not. Even though the error handling in VB6 is quite primitive you can get close to the semantics of Try, Catch and Finally and by doing that you will get a solid structure for the methods in your components already today.
In the article Example of code structure for COM+ component I describe a code structure for a complete COM+ component, but most of the attention is being paid to the error trapping and how to simulate Try, Catch and Finally.

BUILD FOR COM+ AND ITS PROGRAMMING MODEL
COM+ Component Services is dead! Long live .NET Component Services! What I'm saying is that the COM+ programming model that you've come to love, seem to be more or less exactly the same with .NET. (The rumor says that the way to use .NET Component Services will change a bit in beta 2, but that is as far as I know today just rumors.) As a VB-programmer you will with VB.NET get access to more component services than before 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) so my recommendation is clear. Get accustomed to them and use them if you haven't yet!
If you view Moving Duwamish Books To Visual Studio.NET you find that when Microsoft moved their Duwamish Books sample project, they actually kept a lot of the initial design when they ported it to VB.NET. They did change a lot, but most of it stayed as it used to be.

SUMMARY
Hopefully this article has added a whole bunch of tips to your collection of information for how you can prepare yourself 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 components are, the more possible it will be to port you and your components to VB.NET. That is my summarized guess!