Summary

---

Should I Go All the Way with .NET?

Having gone through the process of upgrading an existing VB 6.0 add-in, you must now convert your references to the automation objects from the old IDTExtensibility (VB 6.0) interface to IDTExtensibility (.NET). Once you do that, several questions arise: Should I go all the way with .NET? In other words, should Imove from DAO or ADO to ADO.NET? Should I convert to the use of the new functionality provided by the .NET classes? With respect to add-ins, should I rearrange my code so that I can isolate the references to extensibility objects in a central location as much as possible?

In my opinion, the answer to all of these questions is yes! Obviously, Visual C# is a new language. If you plan to take advantage of the new classes in the .NET Framework, then Visual Basic .NET is like a new language. In some cases, such as the Clipboard object, graphics objects, and the Printer object, you have no choice but to rewrite the code. You can't reference the Clipboard exactly as you've been used to. The Printer object no longer exists. Graphics objects have changed. WinForms aren't structured like VB 6.0 forms were. API calls may require modification or replacement with usage of .NET classes. Once you start to look at the differences, there seems to be no place to stop. In the next few sections, I discuss some of the major areas for conversion and give you a suggested outline for upgrading your add-ins to Visual Basic .NET.

Begin with the Migration Wizard

You could possibly bring code files into a .NET project, one at a time, and correct the obvious errors. Notice that I said "code files". If your add-in has forms, most of them will survive the Migration Wizard. It would be very time consuming to recreate all of the forms from scratch in Visual Studio .NET. In VBCommander for VB 6.0, for instance, I have over 40 forms. You can imagine the work that it would take to recreate those forms. I do have one very complex form in an add-in that came through looking really weird! While looking at the properties for the form, I found that the Migration Wizard had set the BackgroundImage property to some System.Drawing image. Once I set that to Nothing, the problem disappeared and my form looked fine. Figure 13-6 shows this fairly complex form that has been upgraded to a .NET form.

Figure 13-6: B 6.0 form upgraded to a .NET form

Note 

If you examine the code behind the form, you will note some extra code in the initialization code that you would not normally find in a form that is generated by the .NET Windows Forms Designer. It appears to be related to the difference in the way VB 6.0 forms are initialized as opposed to WinForms initialization. Also, VB 6.0 forms could be instantiated directly. In Visual Basic .NET you have to instantiate an instance of a form instead of the form itself.

Even the code modules would be a frustrating exercise to convert manually. The upgrade tool seems to run for an inordinate length of time, but it is doing a lot of work that would take you a lot longer if you did it manually.

Tip 

If you are upgrading a large application using the Migration Wizard, you may encounter hundreds of errors, especially if you have made many separate references to some nonexistent object such as the Printer object.When the caption of the Task List shows "102 Errors", that may not represent all of the errors. The Task List will only show 102 errors at one time.

Use the Add-in Wizard to Create a New Add-in Framework

Because you have to move to the new extensibility model, IDTExtensibility2, you should use the Add-in Wizard to create the basic add-in framework, or Connect class. The methods, parameters, Imports, and Implements are all different in a.NET extensibility Connect class than in a VB 6.0 upgraded Connect class. Also, in using the wizard, you will not have to worry about any of the registration issues.

After you have the Connect class, it is a fairly simple matter to copy the code modules and forms from your upgraded add-in to your new add-in framework created by the wizard. Basically, you are replacing the upgraded VB 6.0 Connect class with a new .NET Connect class. But my recommendation is to copy all of the files from the upgraded add-in to a new directory where you have created the new add-in with the wizard. You can then go to the Windows Explorer, select all of the files that you want to add to the new add-in project, and drag and drop them on the project folder in the Visual Studio .NET IDE. They will be automatically added to the project.

Centralize the References to the Extensibility Object

Throughout this book, I have stressed the need to keep the references to the extensibility objects concentrated in one class where possible. I have shown you how to use such functions as GetCodeFromWindow, GetWholeProc, AddMethodToEndOfDocument, and PutCodeBack to make the references to the extensibility objects. Using this approach limits your exposure to change if you have to make changes to the code that uses the extensibility objects. I realize that this is not always possible, but you should try to do this wherever possible. You should use the Utilities class from the Chapter 12 code as a basis for developing other functions such as the ones just named to perform common, often used functionality for you.

Upgrade to IDTExtensibility2 Objects

Once you add your upgraded add-in files to the new add-in created by the Add-in Wizard, you will have no problem locating code that needs to be changed. The errors will be listed in the Task List. You will have to tackle them one at a time by looking for replacement functionality within the .NET Framework.

Note 

I have tried to cover the most practical automation objects in the course of the various chapters of this book. However, I am sure that I have not covered every object and method that you could possibly desire to use or need. There are some 3,400 objects in the .NET Framework and many of them are related to extensibility. I am sure that you will have to do some digging on your own, especially in the area of the Windows Forms Designer. The objects related to manipulation of forms and their associated components are extremely complex and abstract.

Upgrade to ADO.NET

I confess that a couple of my VB 6.0 add-ins are still using DAO. The problem is not that I do not know ADO. I have been programming in ADO, developing corporate applications, for over 2 years. The problem is that the add-ins worked fine and Les' law number one is "If it ain't broke, don't fix it!" That law is spawned from expediency and from seeing too many programmers try to "fix" code that is working and wind up breaking it.

Now that we're in .NET, DAO has a problem. Bound controls using DAO aren't supported by .NET. So the obvious answer is to upgrade to ADO. And while you're at it, convert to ADO.NET. ADO.NET is so much more powerful; it's the next generation of data access from Microsoft. It is where Microsoft is devoting its time and money with relation to data access.

Note 

If you upgrade an application that uses ADO, the upgrade tool will wrap the ADO COM objects and you can use the code as is. Even so, it is still good to consider upgrading to ADO.NET if you have the time.

If you are not already familiar with ADO.NET, MSDN has lots of examples and there are many books on the market on the subject. Many of the books that are written on the more general subjects of .NET will have a chapter or two on ADO.NET.

Printing in Visual Basic .NET

As I mentioned earlier in the chapter, the VB 6.0 Printer object is no longer supported. Visual Basic .NET provides greatly improved support for printing through classes that control the printing of documents. These new classes allow you to modify print settings and choose printers, and they even allow print preview. The Printer object is replaced in Visual Basic .NET with the PrintComponent. Although the behavior of the two objects is quite different, in most cases the functionality of the old Printer object can be duplicated.

In order to learn how the printing capabilities have changed in Visual Basic .NET, refer to the PrintComponent in MSDN. There are also several examples available on the Microsoft Web site.

Use the .NET Framework Classes

The .NET Framework provides a rich set of classes that will be new to you. I am still learning the ramifications of the statement "Everything is an object in .NET". I constantly see new methods on a simple String object. Take time to explore the options afforded by IntelliSense to a simple String object. You will be amazed at the new and easy ways of doing things. For example, the use of the InStr, Mid, and Left functions can often be replaced with the use of the IndexOf, LastIndexOf, StartsWith, and EndsWith methods of the String object.

Learn to use the new StringBuilder class. It is faster than the String object and is not a resource hog when you are concatenating strings. This is just one example of the great new functionality of the .NET classes.

Use the Macros IDE

Chapter 8 was devoted entirely to the use of macros, the Macro Explorer, and the Macros IDE. At the risk of repeating myself, I cannot overemphasize the power of the Macros IDE in developing and testing code that can ultimately be used in an add-in. By simply substituting DTE for the application object, you can develop and test most add-in code related to extensibility objects in the Macros IDE.

Caution 

There is at least one notable exception to the interchangeability between the Macros IDE and add-ins.You cannot create an instance of IDesignerHost in the Macros IDE.You can still move and resize controls in a macro, but you must use the DTE.ExecuteCommand statement rather than use an IDesignerHost object.

Explore the code that comes in the macro samples. There is a world of ideas and practical working sample code in the samples provided by Microsoft.

Examine the Automation Samples

In Chapter 1, I mentioned that the third CD from Beta 2 contained automation samples. There were many add-ins covering a wide range of subjects in that sample set. If you do not have the Beta 2 CDs, you can find the automation samples on Microsoft's .NET Web site. There are sample add-ins written in Visual Basic, C#, and C++. They will provide a world of information related to add-ins in .NET.

---