Upgrading Is Optional

Upgrading Is Optional

When evaluating your arsenal of applications, it is important to keep in mind that upgrading to Visual Basic .NET is purely optional. It is highly likely that you will have at least some applications that you will never upgrade. Not all applications will benefit from the new features in Visual Basic .NET. Some applications work perfectly already and there is no reason to change them. When evaluating an application for upgrading, the following four upgrade options are available to you:

• Leave it in Visual Basic 6.

• Perform a partial upgrade.

• Perform a full upgrade.

• Perform a partial or full upgrade with interoperability.

Don t Upgrade

Leaving an application in Visual Basic 6 is by far the easiest option. Although you forgo the benefits of Visual Basic .NET and the .NET Framework, you still have an application that runs on a supported platform. This option can be a long-term or short-term one, depending on your business requirements. You may want to put off upgrading for the immediate future, or you may decide that there will never be a need to do it. The one important drawback, worth repeating, is that .NET is the future of the Windows platform. Keeping an application in Visual Basic 6 effectively relegates it to an obsolete platform.

Partial Upgrade

When your application consists of at least two distinct projects (an executable file and one or more ActiveX DLL projects, for example), you might perform a partial upgrade. A partial upgrade occurs when one or more components of an application are upgraded, but not the entire application. This partial upgrade is often a good first step toward a full upgrade, and it gets you many of the benefits without the effort of a complete upgrade.

A partial upgrade involves using the COM interop layer to communicate between the Visual Basic 6 COM and Visual Basic .NET managed components. An example would be a two-tier application using a client-side forms-based project with an ActiveX DLL component containing business logic and data access. You could upgrade the user interface while leaving the ActiveX DLL in Visual Basic 6. The components in the DLL are then accessed by a COM reference in Visual Basic .NET that looks like any other Visual Basic .NET component. Don t let this fool you, though. COM interop does a lot under the covers to make this all possible.

What Is Managed Code?

Throughout this chapter we use the term managed. Managed is the common term used to describe any code that runs under the common language runtime. It refers to the fact that the runtime automatically manages memory, security, versioning, array bound checking, and other run-time services a capability programming languages traditionally have not provided. For example, both Visual Basic .NET and C# create managed executables.

Unmanaged or native code is any code that runs outside the run time. Visual Basic 6 creates unmanaged or native executables, that is, code that runs outside the common language runtime. C⁺⁺ .NET is unique in that it can create managed executables, unmanaged executables, and executables that contain both managed and unmanaged code.

A partial upgrade is the most likely scenario for your large-scale legacy applications. You may have components that you do not want to change or that cannot easily upgrade to the managed world. By performing a partial upgrade, you get the benefit of improved performance and scalability in the components that require it. A partial upgrade is also the fastest upgrade path because you can choose to leave the difficult-to-upgrade code as is. This approach preserves your investment in existing code and minimizes churn in your application. It does have a cost, however, in that the performance improvements will not be as noticeable as in a fully managed upgrade because of the added overhead of the COM interop marshaling layer. COM interop between .NET components and COM components is slightly slower than managed components working together or COM objects working together. This performance impact is not noticeable in most applications highly scalable Web sites and applications that do thousands of calls per second to COM methods are the most affected. Chapter 9 gives you more information on COM interop, including how it works and factors that affect its performance.

Applications with a dependency on COM components are harder to deploy and maintain than applications fully upgraded to .NET since COM objects need to be registered and have versioning issues that .NET objects do not.

Complete Upgrade

A complete upgrade is a purebred. It also requires the most effort. It entails not only upgrading code to Visual Basic .NET but also upgrading all of the technologies to their .NET equivalents. An application that qualifies as a complete (or fully managed) upgrade does not use any COM objects; it uses only the .NET Framework. This option is probably the most attractive for developers, and yet it is also the most elusive for larger, more complex applications. More often than not, with a large code base, portions of your application will need to be rewritten or accessed through the COM interop layer.

Upgrade with Interoperability

Interoperability is a good middle-of-the-road option. It usually means that your application has been upgraded to Visual Basic .NET, while core technologies remain in COM components. Whether the core code resides in a custom DLL of your own making or in other components, like ActiveX Data Objects (ADO) or Microsoft XML Parser (MSXML), the COM interop layer still comes into play. In other words, even though your entire application is in Visual Basic .NET, it is not a pure managed application, and, again, there are certain implications for performance and scalability.