Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET

Peter Kitson

ISBN : 073561587X

Order a printed copy of this book from Amazon.


Cover Design - Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET
 

For your free electronic copy of this book please verify the numbers below. 

(We need to do this to make sure you're a person and not a malicious script)

Numbers

 




Sample Chapter From Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET
     Copyright © Ed Robinson, Robert Ian Oliver, Michael Bond, Ian Oliver



Visual Basic 6 and Visual Basic .NET: Differences


More than three years ago, the Microsoft Visual Basic team set out to create Visual Basic .NET. At that time managers would kid the development team by saying that they were making only three “simple” changes to Visual Basic 6: a new runtime system, a new development environment, and a new compiler. The Visual Basic development team spent the next three years working on one of these changes: the new compiler. Two other teams provided the development environment and runtime. As we pointed out in Chapter 1, the end result is not a new version of Visual Basic 6 but an entirely new product: Microsoft Visual Basic .NET. The name is important for two reasons. First, Visual Basic is still Visual Basic. Second, Visual Basic .NET is not Visual Basic 7.

This chapter describes the three “simple” changes made to create Visual Basic .NET, including changes to the runtime, the development environment, and the compiler. Microsoft also added other features to Visual Basic .NET along the way, including a new forms package and a new debugger, and these are also discussed in this chapter.

.NET Framework vs. ActiveX

As a Visual Basic developer, you will normally not be concerned with the runtime systems that underlie your Visual Basic applications. Visual Basic 6, for example, makes the details of how ActiveX works largely transparent. The Visual Basic 6 runtime handles all of the messy details that come with implementing an ActiveX-compliant component or application. Licensing, persistable objects, Microsoft Transaction Server (MTS) transaction awareness, and binary compatibility are exposed as simple settings that you can turn on or off. In the same vein, Visual Basic .NET does a good job of hiding the details of what happens under the hood. For example, you do not need to know that you are creating or using a .NET component. A .NET component is just like any other component. It has properties, methods, and events just as an ActiveX component does. Why should you care about the differences between ActiveX and .NET if everything basically looks the same?


On the surface, it doesn’t matter whether you’re using ActiveX, .NET, or your best friend’s component model—they all look about the same. When you dig into the details, however, you need to understand the machine that lies beneath.


If you have ever created an ActiveX control in Visual Basic 6, you may have found that it behaves slightly differently from other ActiveX controls that you bought off the shelf. For example, if you add a BackColor property to your control, you’ll notice when you test it that the color picker is not associated with your control. Digging deeper, you’ll find that you need to change the type of the property to OLE_COLOR and set the Property ID attribute on the property to BackColor. Only then will the property behave like a BackColor property. In solving this problem, you needed to cross over from pure Visual Basic into the world of ActiveX. Although Visual Basic attaches different terminology to options and language statements, you end up being directly or indirectly exposed to ActiveX concepts such as dispatch IDs (DISPIDs), what Visual Basic refers to as property IDs, and OLE types such as OLE_COLOR. Visual Basic, as much as it tries, cannot hide this from you. The more properties, events, methods, and property pages you add to your Visual Basic 6 ActiveX control, the more problems you encounter that require an ActiveX-related solution.


Visual Basic .NET works in much the same way. Most of the time, you are just dealing with Visual Basic. However, when you need your application or component to behave consistently with other types of applications, whether they be standard Windows applications or Web service server objects, you will need a detailed understanding of the environment in which you want your application to run. In the case of .NET applications, you will need to understand how .NET works. The more you know about the target environment, the better equipped you are to create a component or application that behaves well in that environment. So let’s dig a bit and uncover the machine that will run your upgraded Visual Basic .NET application: the .NET Framework.

.NET Framework

The .NET Framework is composed of two general parts: the common language runtime and the Framework class library. The runtime is the foundation upon which the .NET Framework is based. It provides the basic services on which all .NET applications depend: code execution, memory management, thread management, and code security. The Framework class library provides building blocks for creating a variety of .NET applications, components, and services. For example, the Framework class library contains the base classes for creating ASP.NET Web applications, ASP.NET XML Web services, and Windows Forms. It defines all of the value types, known as System types, such as Byte, Integer, Long, and String. It gives you complex structure classes such as Collection and HashTable, as well as the interfaces such as ICollection and IDictionary so you can define your own custom implementation of a standard Collection or Hash-Table class.


The .NET Framework as a whole, since it works across all .NET languages, can be thought of as an expanded version of the Visual Basic 6 runtime. The common language runtime corresponds to the Visual Basic Language Runtime in Visual Basic 6, which includes the byte code interpreter and memory manager. The counterparts of the .NET Framework class library in Visual Basic 6 include the Visual Basic forms package, the Collection object, and global objects such as App, Screen, Printer, and Clipboard.


The main difference between the two environments is that Visual Basic 6 is a closed environment, meaning that none of the intrinsic Visual Basic types, such as Collection, App, Screen, and so on, can be shared with other language environments, such as C++. Likewise, Microsoft Visual C++ is largely a self-contained language environment that includes its own runtime and class libraries, such as MFC and ATL. The MFC CString class, for example, is contained within the MFC runtime and is not shared with other environments such as Visual Basic. In closed environments such as these, you can share components between environments only when you create them as ActiveX components, and even then there are a number of limitations. ActiveX components need to be designed and tested to work in each target environment. For example, an ActiveX control hosted on a Visual Basic 6 form may work wonderfully, but the same control may not work at all when hosted on an MFC window. You then need to add or modify the interfaces or implementation of your ActiveX component to make it work with both the Visual Basic 6 and MFC environments. As a result, you end up duplicating your effort by writing specialized routines to make your ActiveX component work in all target environments.


The .NET Framework eliminates this duplication by creating an environment in which all languages have equal access to the same broad set of .NET types, base classes, and services. Each language built on the .NET Framework shares this common base. No matter what your language of choice is—Visual Basic .NET , C#, or COBOL (for .NET)—the compiler for that language generates exactly the same set of .NET runtime instructions, called Microsoft Intermediate Language (MSIL). With each language distilled down to one base instruction set (MSIL), running against the same runtime (the .NET common language runtime), and using one set of .NET Framework classes, sharing and consistency become the norm. The .NET components you create using any .NET language work together seamlessly without any additional effort on your part.


Now that you have seen some of the differences between the Visual Basic 6 ActiveX-based environment and the Visual Basic .NET environment, let’s focus on various elements of the .NET Framework and see how each element manifests itself in Visual Basic .NET. The elements we will be looking at are memory management, type identity, and the threading model. Each of these areas will have a profound impact on the way you both create new Visual Basic .NET applications and revise upgraded Visual Basic 6 applications to work with Visual Basic .NET.