1 INTRODUCTION – Migrate VB6 to .NET
Many organizations have already adopted, or are currently considering adopting, the .NET Framework as their platform of choice for strategic software development. However, in the real world, new versions of languages and new platforms present significant challenges to those adopting these newer technologies both for new development and for migration of existing applications. This White Paper examines some of the issues associated with migrating applications from Microsoft Visual Basic 6.0 (VB6.0) to Microsoft .NET languages. It examines the options for migration and offers some guidelines on best practices that can help organizations for successful vb6 to .net migration.
2 AN OVERVIEW OF .NET Framework
The .NET Framework is an integral Windows component for building and running the next generation of software applications and Web services. The .NET Framework:
• Supports over 20 different programming languages – with 4 core languages supplied by Microsoft namely C#.NET, VB.NET, C++ .NET and J#.NET.
• Manages much of the plumbing involved in developing software, enabling developers to focus on the code associated with the core business logic.
• Makes it easier to build, deploy, and administer secure, robust, and high-performing applications.
The .NET Framework is composed of the Common Language Runtime (CLR) and a unified set of class libraries. Developers can use the .NET language of their choice for code creation and debugging. When compiled with a language specific compiler in the .NET Framework, the language-specific code gets translated into language-neutral and CPU-independent Microsoft Intermediate Language (MSIL).
Before this code can be run, it must be converted by the .NET CLR to CPU-specific code; which is usually done by a just-in-time (JIT) compiler converting MSIL to native code only when actually required.
3 THE BUSINESS CASE FOR MIGRATION
• Increased Productivity and Reduced Maintenance Costs
• Increased supportability
• Web enablement
• Take advantage of the additional features of .NET (Stability, Better organization, Better inline documentation, new features, Security, Deployment etc.)
• Adopt full Object-Orientation (OO)
4 Type of Migration – Porting and Re-factoring
Once an organization has taken the decision to move its legacy code to the .NET Framework, it must decide on its approach to the process. Although individual cases will vary and in most cases a blended approach will be inevitable, the two broad approaches that can be taken are porting and re-factoring.
5 PORTING TO THE .NET FRAMEWORK
Preparatory work for porting concentrates on assessing the suitability of the code base for porting and on identifying problem areas where 1-for-1 code conversion will not be possible. These situations will require intervention with some redesign and code rework and examining the code base from this perspective allows an assessment the level of the rework likely and may suggest that the re-factoring approach would ultimately require less effort than the port.
In the process of assessing the code base there may be an opportunity to prepare it for processing by the VB Upgrade Wizard. Very often large existing VB projects have macro utilities to manage the creation and insertion of standard code constructs such as error-handling and logging. It may be possible to leverage these in order to remove or alter code before it is upgraded to reduce the time it takes to process the code and reduce the size of the issue report it produces.
5.2 The VB Upgrade Wizard
Microsoft Visual Studio .NET offers a VB upgrade wizard to assist in the migration of earlier VB code to VB.NET. This tool attempts to convert code from VB to VB.NET, provides an upgrade report listing any problems encountered and annotates the converted code with comments on conversion issues and recommendations. It also inserts To Do items into the Visual Studio Task List indicating where additional changes need to be made.
5.3 Porting Manually
In the cases where developers responsible for porting code do not want to use the VB Upgrade Wizard, the only alternative is to port the code manually. Code must be examined line-by-line and converted to a .NET equivalent implementation where possible and any unavoidable workarounds hand-coded to suit the particular circumstances and requirements of the code being converted. Whereas the VB Upgrade Wizard might make calls to VB compatibility DLLs as a result of code ambiguities that it has problems interpreting or take the ‘path of least resistance’ in converting, the porting developer may be able to make better choices in these circumstances eliminating or at least reducing the need to retain a reliance on “old VB”.
• VB Upgrade Wizard provides a quick and largely automated route to porting code leaving the developer to fix the aspects that cannot be ported automatically using the guidance provided by the report produced as part of the upgrade process.
• The leg-work of repetitive code conversion can safely be left to the tested functionality of the wizard whilst the coder can concentrate on the ‘tricky’ bits.
• In theory assessing code for line-by-line porting has less dependence on a need for a strongly documented design of the existing system – as the structure will not change there is less emphasis on understanding of the design than on understanding of VB and COM fundamentals such as finalization and data access.
• In principle, the code produced will require less testing and review because of its closeness to the original code base and the fact that much of the ported code continues to use VB compatibility DLLs means that the emphasis is on safety and workability.
• The VB Upgrade Wizard necessarily takes the path that is safest and the one of least resistance which is unlikely to be the most efficient or logical. The resulting code base produced by the wizard is almost always a hybrid of .NET code and calls to VB compatibility libraries, making the move to .NET a nominal one to a large extent.
• Whether arrived at via the Upgrade Wizard or through manual porting, the introduction of a dependency on COM interoperability and older VB libraries may hamper future efforts to move the code base further into the .NET world. Additionally, the reliance of older VB6.0 libraries introduces a risk for code support relying as it does on their continued support by Microsoft.
• Many of the business case drivers identified in our examination of the case for migration are not addressed by porting code: its essential internal structure and architecture remain the same meaning that its supportability, maintainability and overall code quality are not improved; and mechanically converting code by porting does not offer the opportunity to take advantage of .NET’s new features.
6 RE-FACTORING WITH THE .NET FRAMEWORK
Re-factoring an application involves a much greater understanding of its design and implementation. In preparing for a re-factoring migration it is important to make sure that the system is well documented with an up-to-date specification and set of design documentation.
One of the goals in redesigning a VB6.0 solution and re-implementing it in the .NET Framework is to realize the benefits of Object-Orientation such as code reuse and more efficient structure. In order to do this the system must be comprehensively understood and redesigned using Object-Orientation principles. This analysis and design preparation obviously represents a greater short-term cost and effort than that associated with porting but carries the potential of realizing much greater long-term benefits. In addition to a good understanding of the existing system, re-factoring requires expertise in Object- Orientation design and best practice.
Where the scope of the work includes the introduction of new functionality or a fundamental design change a targeted re-design from the bottom up is likely be the most appropriate approach. However, as with any project, if new functionality is being introduced it obviously needs to be managed carefully with a clear statement of requirements and definition of the required additional functionality.
• Re-factoring is a chance to make a break from the older world of VB and realize the benefits of re-designing and implementing systems to take advantage of Object-Orientation and newer technologies such as the internet and XML.
• The goals of better supportability and maintainability through better design and code-quality can be achieved without the constraints and potential future liabilities of retaining dependence on interoperability and legacy VB DLLs.
• Re-factoring also represents a chance to take a pattern-based approach to re-design and implementation that wouldn’t be possible with porting – common solutions to common design scenarios can be approached in terms of existing documented patterns and implemented in reusable modules that can be applied across the system for common needs such as data-access, message management, error & activity logging and so on. This offers benefits in terms of speed of design, reusability, supportability and testing.
• The goal of escaping the world of COM and older VB may not be fully realizable if the re-factored systems still have to rely on services not currently available through .NET such as distributed transaction support or where the systems must make use of third-party integration components that are COM based – many of Microsoft’s own products are yet to be .NET-enabled and still rely on COM interfaces for integration and automation – Microsoft Office for example.
• With an effective re-design of a system there will be the temptation to take advantage of the situation to introduce new functionality. Many organizations will build wish-lists of future requirement requests between application releases and the option to roll these features into a re-factoring migration may be appealing. Whilst there may be very good sense in taking advantage of this opportunity and some very easy “wins” to be gained at very little extra expense and effort, there is a danger that without proper control the situation could turn into a free-for-all with everything being “up-for-grabs”.
• Re-factoring systems may give rise to problems with interactions, dependencies and interfaces to other systems that are not being migrated at all or are being ported rather than re-factored. There is a potential “domino-effect” of changes in re-factored systems’ interfaces or behaviors forcing change on systems outside the boundaries of the re-factoring efforts. In these cases the external systems may prove to be immutable forcing compromise or further work on the re-factored systems to accommodate the constraints that the external systems represent. At the very least problems may be encountered in defining and maintaining system-boundaries in order that the scope of the re-factoring does not creep into other systems and impose extra re-work and consequent cost upon them.
7 REAL WORLD MIGRATION
7.1 Migration Paths
In the real world an actual migration activity for a system is likely to involve a combination of the porting and re-factoring approaches. The following section describes the paths available through migrating an application and the options for applying porting and re-factoring techniques at the various stages in the process.
In the Visual Basic migration path there are three possible exit points from the process:
1. The migration activity ends after the most basic of porting activities using the VB Upgrade Wizard after any (optional) preparatory parsing of the code base for efficient processing by the wizard. It is the fastest and least demanding of approaches but carries many of the risks described above.
2. Here a fuller port is carried out beginning the process above followed by a second stage of converting all library calls to use the .NET Framework instead of using the backward compatibility libraries; this represents a significant amount of work and needs to be done manually by skilled .NET developers. The advantage here is that the target language is VB.NET where the keywords are familiar.
3. Here a further stage is added after the two above, to convert the syntax to C#.NET. This allows the organization to adopt C# as its language of choice if it desires and does not add significant overhead since the majority of the migration effort will occur at stage 2 above, in changing the library calls into the .NET Framework.
It is clear that the move from VB6 to .NET Migration is not a simple matter of running a one-off conversion tool (if it were the process would not be a matter of discussion). Many factors affect the approach, a great many of which are not technical.
It is not possible to say in general whether opting for porting or for re-factoring is most appropriate without assessing individual migration projects in the light of the strengths and weaknesses of each approach. In most cases the combined business/technical factors will force a blend of approaches to be adopted.