After you have made the decision to upgrade, we recommend you to use chapter 4 to learn about the possible VB and .NET application types and how each type should be upgraded. Remember that your first goal is to achieve functional equivalence between the legacy and upgraded versions, and being aware of potential problem areas can lessen the impact those problem areas will have on your VB to .NET application migration. For example, when executing an ASP to ASP.NET migration, take into account that Microsoft provides a free tool for automatically upgrading ASP pages to ASP.NET, and although the tool does not automatically convert all of the ASP features, it can simplify the project by automating some of the steps.
Common Application Types
Desktop and Web Applications
Porting the ASP Application to ASP.NET
Application Components
ActiveX Controls
Distributed Applications
The Visual Basic Upgrade Wizard supports different Visual Basic 6.0 application types, including standard executables (.exes), ActiveX components, and Internet Information Services (IIS) applications. Depending on the original project type, the upgrade wizard generates a .NET project whose output is a Windows-based application (.exe) or a class library (a dynamic link library, or DLL).
It is very important that you evaluate the architecture and type of your upgraded application. For example, you can transform a highly coupled or monolithic desktop application into an application that includes several independent components in well-defined tiers and takes advantage of technologies provided by Visual Basic .NET.
Desktop and Web applications are two basic frames that include all of the components and source code that make up an application. When you upgrade a desktop or Web application, you should consider the components and their interconnections, the structure of each component, and the overall application architecture.
A desktop application can require considerable effort to upgrade to the .NET Framework. One of the difficulties in upgrading an application is because Visual Basic has been completely redesigned for the .NET Framework, and functions and controls do not correspond exactly to their counterparts in Visual Basic 6.0.1
You may need to approach the upgrade by using one of the following two approaches:
Single-tier (or monolithic) applications are applications in which most or all of the code for a given feature is contained in a single source code file. In Visual Basic, this usually means that all of the functional logic is in the control event handler subroutines. All necessary components and functionality are included in a group of forms, making them the conceptual units for the application features. In such applications, development tends to be driven by the user interface.
This kind of application is highly coupled because all components are closely tied together, usually in the same file or procedure, with many shared structures and connection points. A single-tier application also has low cohesion, which means that the mechanisms that constitute different conceptual entities are so closely tied together that conceptual barriers are obscured. This makes modifying functionality difficult because making a change can affect more than just the intended functional behavior.
The best strategy is to redesign the application and separate its functionality into distinct parts. This approach provides modularity and functional cohesion, making it easier to modify pieces of the application, add or remove functionality, or make functionality available to other applications.
Using a vertical strategy to upgrade parts of your application to the new architecture provides an effective test bed for the new design. The .NET Framework provides architectural support that makes it much easier to build on an upgraded base.
A two-tier application is composed of a first tier — the user interface tier — that contains a user interface and business logic, and a second tier — the data tier — that contains all of the data access components.
The user interacts with the interface tier, and uses it to perform all application-specific functions. The data tier contains all data sources and manages them so that they can provide all necessary data services to the user interface tier.
A two-tier application can be upgraded horizontally or vertically. If you select a horizontal strategy, you can update an entire tier and leave the remaining tier unchanged. The upgraded tier can use interoperability features to work with the tier that was not upgraded. You can then upgrade the remaining tier and integrate it into the target application as time and budget permits. Alternatively, you can use a vertical upgrade strategy.
When you upgrade a two-tier application, the upgrade wizard produces a Visual Basic .NET project that contains files and references similar to those produced for a single-tier application. The main difference is that a data access class is included in the project files. This class is independent of the other classes and provides services that can be used by any other class.
A three-tier application maximizes component cohesion and minimizes tier coupling. This architecture uses three different tiers for the different aspects of the application: a user interface tier, a business logic tier, and a data tier.
Additionally, it allows you to take advantage of specialized skills that your developers may have, and have them work in parallel. For example, one developer or development team could work on modular user interface components while other developers upgrade and adjust the components in the business logic and data access tiers.
The difference between a three-tier and a two-tier application is the addition of a business logic tier.
The business logic tier contains application rules and algorithms; therefore, the user interface tier is only responsible for managing the interaction between the user and the application.
You start by using the standard executable project template. By default, this template starts with an empty form that becomes one of the primary interfaces. The Visual Basic 6.0 integrated development environment (IDE) allows you to include supplementary components and references to take advantage of existing functionality.
In general, a desktop application had the following characteristics:
Language issues. You may need to perform additional manual upgrading to resolve language issues, such as external DLL function declarations or thread safety. This work can include creating or changing classes so that they provide basic API services or synchronization among objects. You can upgrade external declarations to .NET Framework classes and new interface classes. In addition, you may need to add references. Note that Visual Basic .NET components (including UserControls) are not inherently thread-safe. Multiple threads are allowed to access a component simultaneously. As a result, code that is thread safe in Visual Basic 6.0 can be unsafe when it is upgraded to Visual Basic .NET.
This change will affect you if you are running your component in a multithreaded environment such as Internet Explorer, Internet Information Services, or COM+.2 In this case, you must include new synchronization mechanisms to ensure thread safety.
Form issues. Dynamic data exchange (DDE) and drag-and-drop functionality can cause upgrade issues. Neither Visual Basic .NET nor the .NET Framework support DDE. Because Visual Basic drag-and-drop is considered an outdated feature, the upgrade wizard does not upgrade drag-and-drop – related code.
Instead, it preserves the Visual Basic 6.0 drag-and-drop code in the upgraded Visual Basic .NET project. The code will not compile; therefore, you must either delete it and remove the drag-and-drop functionality or change the code to use OLE drag and drop.
ActiveX control upgrade. The upgrade wizard supports most ActiveX components. The upgrade of these components takes advantage of the interoperability that can be built around the original component. However, if an application control is not supported, you must reimplement and re-architect some application functionality, particularly in the user interface. In applications that make extensive use of complex third-party controls, you should perform limited upgrade tests with a simplified user interface. This will help you to determine how many controls are fully or partially supported.
To deploy an upgraded .NET desktop application, you must do the following:
In most cases, you would use the following technologies:
Yes. However, they are executed as different, non-communicating processes. A Web application within a site can contain both ASP.NET pages and ASP pages. This offers some advantages if you need to move a large, functionally disjointed and rapidly changing site to ASP.NET one piece at a time. You can upgrade different sections of the application that do not depend on each other to ASP.NET, and they can coexist with the rest of the application. If you are transitioning to ASP.NET as a long-term strategy, you should use this opportunity to make as many architectural and design improvements as you can.
Yes. Microsoft provides a free tool for automatically converting ASP pages to ASP.NET. The tool does not automatically convert all of the ASP features, but it can simplify an upgrade project by automating some of the steps. To download the migration assistant, see “ASP to ASP.NET Migration Assistant” in the Microsoft ASP.NET Developer Center on MSDN.
If you are upgrading an enterprise application that uses ASP, you may need to use two different upgrade assistants. If the application has a business logic tier, user-defined classes in the data access tier, and additional components that run on an application server, you should use the Visual Basic Upgrade Wizard. After you successfully upgrade these foundation components, you can convert the ASP code by using the ASP to ASP.NET Migration Assistant.
You can approach this work in one of two ways:
When you upgrade existing ASP pages to ASP.NET pages, you should also be aware of the following:
You can create the following types of COM components:
An assembly is the primary building block of a .NET Framework – based application. It is a component library that is built, versioned, and deployed as a single implementation unit. Every assembly contains a manifest that describes that assembly.
Currently two versioning problems occur with Win32 applications:
These versioning problems combine to create DLL conflicts, where installing one application can inadvertently break an existing application because a certain software component or DLL was installed that was not fully backward compatible with a previous version.
The .NET CLR provides assemblies as a means to achieve the following goals:
When you upgrade application components from Visual Basic 6.0 to Visual Basic .NET, you should take into consideration the interoperability capabilities of the .NET CLR. For example, you can upgrade a third-party component through different mechanisms, including interoperability wrappers, upgrading to .NET Framework components, and upgrading to third-party components designed for Visual Basic .NET. You should select the appropriate option for your application by considering the effort required, the expected results, the available resources, your future application development plans, and other factors.
There are several reasons why you might want to put an assembly in the global assembly cache:
An ActiveX control is a COM component with user interface elements. ActiveX controls were previously known as OLE controls or OCX controls. These controls can be used in the same way as any of the standard built-in controls, and provide an extension to the Visual Basic 6.0 toolbox. ActiveX controls created in Visual Basic can be used in different container applications, including Visual Basic applications, Microsoft Office documents, and Web pages ccessed through a Web browser like Microsoft Internet Explorer.
You can insert ActiveX controls in Web pages by using the <Object> HTML tag. This tag receives a ClassId parameter that corresponds to the ActiveX component identifier. The identifier is required so that the component can be registered on the client computer and instantiated and displayed correctly by the Web browser.
You can achieve functional equivalence for an upgraded Web application by leaving embedded controls inside Object tags. If the original ASP application included server-side components, you can wrap these components by using the interoperability feature.
ActiveX documents are COM components that must be hosted and activated within a document container. They provide the application functionality; they also provide the ability to persist and distribute copies of the data intrinsic to the application.
These components can be used on HTML pages or as alternatives to HTML pages, and they can be deployed so that users can navigate transparently between ActiveX documents and other pages in the application or Web site.
A distributed application is one in which some of the application components are executed on remote computers and there is interaction between local and remote components. To have an effective interaction between these components, you must use numerous basic services, such as communication protocols, security, and resource locator services. A distributed application offers important advantages for the enterprise environment, including improved scalability, reliability and failure tolerance.
The distributed component object model (DCOM) extends the component object model (COM) to support communication between objects on different computers on a local area network (LAN), a wide area network (WAN), or even the Internet.
With DCOM, your application can be distributed to any location that makes sense to your users and to the application.
This alternative has the following advantages:
The main disadvantages of this approach are:
Understanding the possible application types that you may need to upgrade will help you to better understand how each type should be upgraded. Each type has features that are easy to upgrade and features that are hard to upgrade. Being aware of potential problem areas before you begin can lessen the impact those problem areas will have on your upgrade process.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com
