Selecting Projects to Upgrade

Selecting Projects to Upgrade

Selecting projects for upgrading is generally a straightforward process. Some applications are no-brainers (they will be upgraded no matter what); others are trivial enough that the upgrade process can be handled in a matter of days. On the other hand, more-complex applications can require much more thought and consideration. Multitiered applications using a wide variety of technologies or applications that are just really big can require an upgrade process that is accomplished in stages over an extended period of time.

For most applications, the selection process goes like this:

1. Evaluate the benefits of upgrading the application to Visual Basic .NET. What features do you need or would you like to take advantage of?

2. Evaluate the effort required by the upgrade. What will have to be rewritten or modified?

3. Develop an upgrade plan. Will the upgrade be handled in stages, or will it be done all at once? Will some or all COM objects be upgraded to their Visual Basic .NET equivalents?

Figure 3-2 illustrates this process.

Figure 3-2

Upgrade decision process.

Evaluating the Benefits

To evaluate the benefits of upgrading, you must carefully examine your application and its architecture, components, and business requirements and determine an upgrade strategy. Ask yourself if it is worth just upgrading to Visual Basic .NET without moving from ADO to ADO.NET or moving from the SOAP toolkit to XML Web services, for example. Decide whether upgrading in stages makes sense.

Whatever governs the project selection process, it is important to keep value at the forefront of your mind. Ask yourself whether the upgrade will enable your application to support new features and technologies that provide benefits. Ultimately, if there is no value in either the upgrade experience or the result, you are probably dealing with a project that will live on perfectly happy as a Visual Basic 6 application until it is replaced or circumstances change. The five most common reasons to upgrade to Visual Basic .NET are

• To standardize all your applications on a single platform

• To upgrade a pet project

• To take advantage of new language features and improved application architecture

• To increase performance and scalability

• To take advantage of the .NET Framework

The Value of Standardization

While using standardization as a justification for upgrading a project may seem somewhat facetious, it is often important to larger organizations. It s not unrealistic to assume that a good portion of new Visual Basic development within your organization will be done using Visual Basic .NET. If this is the case, it makes sense to move applications to a single consistent platform. Savings on training is one of the most obvious reasons, but using one platform also enables developers to move between applications without having to switch between their Visual Basic 6 and Visual Basic .NET hats.

The Infamous Pet Project

Let s face it: We all have pet projects. In fact, the majority of critical business applications started as somebody s pet project at one point or another. Most of us want our pets to survive, grow, and thrive.

New Features, New Language

While it may have some detractors, Visual Basic .NET is pretty cool. It includes a whole host of features that finally make Visual Basic a player in the object-oriented world. Sometimes the benefits of upgrading to Visual Basic .NET are immediate and obvious. A case in point is inheritance. We are all familiar with the practice of implementing common interfaces and code within Visual Basic:

1. Open a class file.

2. Select all and copy.

3. Create a new class file and paste.

4. Make your changes to adapt this copied class to your needs.

The problem is that this approach generates a whole lot of duplicate code and is a maintenance headache. Inheritance in Visual Basic .NET offers a much better solution.

We found that implementing inheritance in one project containing a host of similar classes that represented various related functional tasks resulted in a 75 percent reduction in overall code size. The benefits were immediate and tangible. Bug fixes were simplified and required less work to implement. (They needed to be fixed in only one place instead of in many.) Upgrading also made it possible to implement a consistent error-handling scheme across all classes, resulting in a much cleaner project.

Performance and Scalability

Do you have a performance-critical application? Does your application need to be scalable, and is performance key to the success of the application? If so, you will definitely want to upgrade your application to Visual Basic .NET. Visual Basic .NET and the .NET Framework have features that can improve scalability and performance in most applications when used correctly. The ADO.NET data access object model, for example, provides in-memory local data caches and a data reader object that is optimized for speed. Also consider that ASP.NET pages are compiled and have improved caching mechanisms and dramatically enhanced session state management capabilities.

Two examples of major contributors to improved application performance are the SqlDataReader and StringBuilder utility classes. Let s take a quick look at what these features can do for you.

Fast SQL Server Access

The SqlDataReader class is analogous to the Forward-Only cursor Recordset from ADO. It is a network-level data provider that offers a low-overhead object model and fast queries to Microsoft SQL Server databases. The result is that you can often double your data performance just by substituting SqlDataReader for a classic ADO Recordset. For more information on upgrading your existing ADO code to ADO.NET, see Chapter 20.

String Concatenation

Not everyone realizes that a major problem area for performance in Visual Basic 6 is string concatenation. This is a very wasteful operation with no real alternatives, other than rolling your own solution (usually as a C++-based COM component). In Visual Basic .NET, it is still possible to do the same old string concatenation, but there is a new utility object that provides fast and efficient string manipulation: StringBuilder. StringBuilder is a class found in the System.Text namespace.

How Fast Is Fast?

Here is an easy example that demonstrates the performance difference between string concatenation and StringBuilder:

Sub StringTest()    Dim before, after As DateTime    Dim diff As Double    before = Now()    SlowString()    after = Now()    diff = (after.Ticks - before.Ticks) / Math.Pow(10, 7)    Debug.WriteLine("Standard concat: " & diff)

   before = Now()    FastString()    after = Now()    diff = (after.Ticks - before.Ticks) / Math.Pow(10, 7)    Debug.WriteLine("String Builder: " & diff) End Sub Const loopMax As Integer = 20000 Function SlowString() As String    Dim str As String = "MyString "    Dim i As Integer    Dim result As String = ""    For i = 0 To loopMax       result &= str    Next    Return result End Function Function FastString() As String    Dim str As String = "MyString "    Dim i As Integer    Dim result As New System.Text.StringBuilder()    For i = 0 To loopMax       result.Append(str)    Next    Return result.ToString() End Function

When we ran this code on a laptop, the results showed that using StringBuilder was more than 200 times faster than simple string concatenation. In other words the FastString() method can be called approximately 200 times in the same time period it would take SlowString() to complete just once. An added benefit is that the FastString() method required less memory than the SlowString() method.

When you re concerned about scalability and performance, Visual Basic .NET definitely has a lot to offer.

Plenty More Where That Came From

Of course, the performance improvements are not limited to the SqlDataReader and StringBuilder classes. They are merely two examples from a vast application framework that offers much, much more. Isolate the performance-critical areas of your application, list the technologies that are used, and then research the .NET equivalents. Most of the time, options exist that can dramatically improve the application s performance.

	Because of the architectural differences in the common language runtime, ASP.NET, and ADO.NET, it is possible, with a fully upgraded application, to see up to a fivefold increase in performance over an equivalent ASP/Visual Basic 6/ADO application based on real-world systems. A twofold gain is far more typical, however.

The .NET Framework

We ve talked about the performance advantages of Visual Basic .NET, but the .NET Framework also has many compelling features that are not exclusively performance related. XML Web services are an excellent example of such a feature. Others are remoting, reflection, and a GDI+ graphics model, for starters.

Moving On

That sums up the benefits of upgrading to Visual Basic .NET. If you re still planning to forge ahead, it s time to move on to evaluate the effort that the upgrade will require.

Evaluating the Effort Required

Four main physical factors determine an application s suitability for an upgrade:

• Architecture

• Code quality

• Technologies

• Size

The sections that follow discuss each of these factors in turn.

Application Architecture

The overall application architecture will play a large part in the determination of whether and how to upgrade an application. An application that is Web based, has a simple architecture, and demands high availability and responsiveness would be a good candidate for a complete upgrade. On the other hand, if the application is form based and has any or all of the following attributes, you might prefer either to take a tiered approach to the upgrade or to forgo the upgrade altogether:

• Has a small user base

• Uses the Visual Basic 6 drawing model

• Contains many unmanaged Win32 API calls

• Contains old code that uses obsolete language elements

It may be that some or all of your Visual Basic 6 applications can take advantage of the new features in Visual Basic .NET. You may even want to convert your legacy client/server applications to a thin Web-based client model with the improved Web controls.

Although many variations are possible, the following are the four general types of Windows application architectures.

ASP Web applications This type of application is usually performance driven and needs to be scalable to support hundreds or thousands of concurrent users across the Internet or intranets. It is one of the simplest kinds of applications to upgrade to ASP.NET because of the similarities between the two technologies. ASP components on the client end can, with some effort, be converted to ASP.NET using any of the managed languages. Middle-tier components written in Visual Basic 6 can be upgraded using the Visual Basic .NET Upgrade Wizard, the data access components can be converted to ADO.NET, and any third-party components can be accessed through the COM interop layer. By their nature, these applications depend on performance and scalability two things the .NET Framework delivers. All other factors being constant, this type of application will probably see the biggest benefit from an upgrade. The one downside to upgrading ASP applications is that there is no upgrade tool to do the grunt work for you. The middle-tier components can take advantage of the Upgrade Wizard, but the ASP pages all need to be upgraded by hand.

Forms-based client/server applications A typical application that uses this architecture consists of a fat client, possible middle-tier COM components with business logic, a data access layer, and a connection to a data store. These applications are different from thin client/server applications in that some of the processing and business logic resides in the client. Fat-client systems come in all shapes and sizes, some with ActiveX controls and active documents embedded in a Web browser and others with client-installed executables, COM components, and third-party controls. Unless their design is fairly straightforward, these applications require more work to upgrade to the .NET Framework. Since the middle-tier components are much the same as in a thin-client system, the upgrade of the middle tier will not pose any more of a problem than upgrading a thin-client system. However, upgrading the client may be more difficult than the transition from ASP to ASP.NET for thin-client systems. The difficulty in upgrading the client lies in the fact that Visual Basic has been completely redesigned for Visual Basic .NET, and the functions and controls do not map exactly to their counterparts in Visual Basic 6.

Enterprise architecture with legacy or distributed systems Applications that contain back-end legacy systems, such as mainframes, can greatly benefit from Visual Basic .NET and its new features. Rewriting portions of the system to take advantage of the new XML Web services application architecture can improve code modularity and maintainability and can also increase accessibility to those legacy systems. With XML Web services, it is possible to expose and consume the functionality and data of the legacy system essentially by writing a wrapper component that exposes its interfaces through an XML Web service. This allows local and remote clients or components to easily interact with and program against the legacy system. The problem here is that any performance or scalability benefits would be hard to achieve, since the legacy systems are more often than not the performance bottlenecks. Although there might not be a huge performance benefit, your application can benefit architecturally by becoming more distributed and more flexible. XML Web services enable this by using SOAP as the underlying implementation, which is more flexible than DCOM in many ways.

Stand-alone applications Stand-alone applications are typically form-based applications such as games, graphics programs, controls, or general-purpose utilities. Simple applications are typically easy to upgrade.

Code Quality

Code quality will have a great deal of influence on an upgrade strategy. Some of the factors that will make your Visual Basic 6 application easier to upgrade include a modular, object-oriented design and good programming etiquette. This is not to say that applications that do not follow these principles are not upgradable, but the task will involve more effort. As a test, you can run the Upgrade Wizard and see what issues it discovers. See Chapter 4 for a more in-depth treatment of good coding practices.

Technologies

The technologies or Visual Basic 6 features that an application uses also affect the amount of effort required to upgrade an application. A typical area of difficulty involves the use of either many Win32 declared functions or the Visual Basic 6 graphics model. The Upgrade Wizard can t really do anything with the declare statements, so it will leave them alone. But they should still work, with a few exceptions (which will be highlighted by the Upgrade Wizard). The Visual Basic .NET graphics model, on the other hand, is so different from what was available in Visual Basic 6 that there is no direct or indirect equivalent. Any code that uses the Visual Basic 6 drawing model will have to be rewritten. There is just no way around this.

Application Size and Scope

This point may be self-evident: a larger code base will take more time to upgrade. When you re becoming familiar with the .NET Framework, it is best to start with smaller applications. That will give you a chance to become acquainted with the new constructs, and debugging problems will be easier. Take the code size into consideration when screening applications to upgrade.