Moving From Visual Basic 6.0 to .NET
Content
Charteris White Paper
Moving from Visual Basic 6.0 to .NET
Version 1.0 Gordon Mackie ([email protected]) 23 August 2004
©2004 Charteris plc
1. 2. 2.1 2.2 2.3 3. 3.1 3.2 3.3 3.4 3.5 3.6 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 5.5 5.6 6. 6.1 6.2 6.3 6.4 7. 7.1 8. 8.1 8.2 8.3 8.4 9.
INTRODUCTION AN OVERVIEW OF .NET What is .NET? The .NET Framework Developing in .NET THE BUSINESS CASE FOR MIGRATION “If it ain’t broke…” Increased Productivity and Reduced Maintenance Costs Increased supportability Web enablement Take advantage of the additional features of .NET Adopt full Object-Orientation (OO) KEY DECISIONS The Main Decision A Language of Choice How to re-skill Type of Migration – Porting and Re-factoring PORTING TO THE .NET FRAMEWORK Preparation The VB Upgrade Wizard Porting Manually Target Language Pros Cons RE-FACTORING WITH THE .NET FRAMEWORK Preparation Target Language Pros Cons REAL WORLD MIGRATION Migration Paths MANAGING MIGRATION ACTIVITIES Operational Considerations Budgetary Constraints Control and Boundary Definition Technical Issues CONCLUSIONS
3 4 4 4 4 5 5 5 5 5 6 6 8 8 8 9 9 10 10 10 10 10 11 11 12 12 12 12 13 14 14 16 16 16 16 16 17
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 2 of 17
1.
INTRODUCTION
Many organisations have already adopted, or are currently considering adopting, the .NET Framework as their platform of choice for strategic software development. One of the reasons often given for the move is that use of the .NET Framework protects investment in existing software development language skills such as Visual Basic and C++. The argument put forward is that if the NET framework continues to support these programming languages then developers of new projects based upon .NET will have a flying start through use of programming languages with which they are already familiar. Likewise many consider it must be a fast-track for those moving old code to the new platform as the same programming languages are used in both environments. However, in the real world, new versions of languages and new platforms on which they are implemented, present significant challenges to those adopting these newer technologies both for new development and for migration of existing applications. This Charteris White Paper examines some of the issues associated with migrating applications from Microsoft Visual Basic 6.0 (VB6.0), and earlier versions of COM-based Visual Basic, to Microsoft .NET languages including Visual Basic .NET (VB.NET). It examines the options for migration and offers some guidelines on best practices that can help organisations to successfully migrate their applications to the .NET world. For clarity in this document, we make the distinction between the concepts of porting and re-factoring in discussing the process of migrating software applications. We define porting as the process of taking COM-based VB 6.0 or earlier code and converting it to .NET code without changing the basic architecture or design. We define re-factoring as re-working a software solution in the process of moving it from COM-based VB 6.0 or earlier code to .NET code such that its feature set and functionality are retained, but that its internal implementation may be significantly different. In later sections we look at the issues involved both in porting code and in re-factoring solutions.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 3 of 17
2.
2.1
AN OVERVIEW OF .NET
What is .NET?
Microsoft defines .NET as “a set of Microsoft software technologies for connecting information, people, systems, and devices. It enables a high level of software integration through the use of Web services—small, discrete, building-block applications that connect to each other as well as to other, larger applications over the Internet.” Whilst Microsoft has in the past sought to brand (and re-brand) much of their software product set under the general umbrella of .NET, the true newer technologies that constitute .NET as far as the software development community is concerned are: ♦ The .NET Framework, which is used for building and running all kinds of software, including Web-based applications, smart client applications, and XML Web services. ♦ Developer tools, such as Microsoft Visual Studio® .NET 2003 which provides an Integrated Development Environment (IDE) for maximizing developer productivity with the .NET Framework.
2.2
The .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 than ever before to build, deploy, and administer secure, robust, and highperforming applications. The .NET Framework is composed of the Common Language Runtime (CLR) and a unified set of class libraries.
2.3
Developing in .NET
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.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 4 of 17
3.
3.1
THE BUSINESS CASE FOR MIGRATION
“If it ain’t broke…”
Whilst adopting .NET as a platform for new development projects can be seen as a relatively straightforward strategic decision on the part of an enterprise, the migration of existing applications to the .NET environment might be seen as a more questionable one. Systems that have already been developed and implemented using tools and technologies from the world of COM and which are performing their functions quite satisfactorily do not necessarily have to be moved to the .NET world. The old adage that: “if it ain’t broke, don’t fix it” could quite easily apply were it not for some arguments for migration that in many cases are compelling. The following sections examine these.
3.2
Increased Productivity and Reduced Maintenance Costs
Probably the biggest advantage offered by .NET is that much of the code that would previously have had to have been written on a bespoke basis can now be considered as “part of the plumbing” provided by .NET. No longer does the programmer need to write a mass of code to cope with, for example, memory management and garbage collection but instead s/he can focus their skills on developing business logic to meet the business need. The impact of this is that programmers are typically far more productive in delivering finished product. The corollary of having the development team focus on producing code focussed on the core business logic is that there is less code to go wrong: the infrastructure provided by .NET has been tested and is supported by Microsoft and hence is not going to need to expensive attention usually required for bespoke code. As .NET is still relatively new the skill base is still growing and hence there is a premium on hiring people with .NET skills. However, over time more and more developers will become skilled in the .NET languages such as VB.NET and C#.NET. After taking the costs associated with using one-off conversion tools in to consideration, the cost of skilled resource to perform development and maintenance tasks will soon correspond to that for the older environments. When combined with the increased productivity and the reduced maintenance costs the overall cost advantage in using .NET is significant.
3.3
Increased supportability
There is a risk in not adopting .NET. As .NET has gained significant momentum in the development community there will be fewer and fewer developers available with the skills or inclination to work with older languages. This will mean that writing code for new applications or maintaining older ones in the older codebases, will become more expensive and harder to resource. This risk is compounded by the fact that Microsoft will ramp down support for VB6.0 in 2005. So migrating to .NET will reduce the risk of being dependent upon a disappearing Microsoft product support structure. With progressively fewer developers available to support VB6.0 applications in the future, migrating to .NET means that business-critical applications will continue to enjoy support for the underlying technologies from Microsoft. One could argue that the same may happen to .NET as is now happening to VB6.0. However, this is unlikely as Microsoft have already announced that the roadmap for the next generation of their operating systems (codenamed Longhorn) will have an integral component - WinFX, which will extend V2.0 of the .NET Framework incorporated in Visual Studio 2005 (due to be released next year), adding APIs for a new graphical user interface subsystem (Avalon), a new file subsystem (WinFS) and a new Web Services messaging subsystem (Indigo). Hence, one can be confident that the approach to future developments is more one of evolution rather than the distinct shift that we have seen with the introduction of .NET.
3.4
Web enablement
Although web development was, and is, possible using the COM-based technologies in VB6.0 and earlier versions of Visual Basic, such capabilities were add-ons to the core functionality and not built-in
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 5 of 17
to the heart of their structure and operation. In contrast, the .NET Framework is oriented very much towards using the internet and its associated messaging protocols as the preferred way of developing and integrating applications. The .NET Framework is essentially designed bottom-up to support fast-emerging standards such as the Simple Object Access Protocol (SOAP) which allow applications to communicate with each other across networks and the internet using XML Web Services. Migrating to the .NET Framework means that these standards can be embedded by default into the applications that organisations write, increasing their ability to communicate with external applications.
3.5
Take advantage of the additional features of .NET
There are many key benefits and improvements that the .NET Framework provides over VB6.0, these include: ♦ Stability – .NET is not prone to the memory leak problems often encountered in the COM world. Because the .NET Framework is type-safe and uses the in-built Garbage Collector to reclaim memory, memory allocation and release is no longer the responsibility of the applications developer, nor of the developers of any libraries s/he uses. Additionally, the .NET assemblies have greater control over mutual component-compatibility levels eliminating many problems with deployed libraries of mismatched versions. ♦ Better organisation – The Framework Class Libraries offer a well structured and documented set of features, organised into logical namespaces. These are accessible to all .NET languages and provide a better coding model than that of older Visual Basic versions with their inconsistent use of keywords, object-references and API declarations to extend and enhance language functionality. Developers can take advantage of namespaces too, for organisation and logical grouping of their own code. ♦ Better inline documentation – In C# .NET, XML documentation offers the ability to add rich code annotation that can be used to generate help documentation and intellisense for code artefacts. VB.NET will have XML documentation in the next release of Visual Studio (Visual Studio.NET 2005) and third-party add-ins are available that emulate it in the current version. ♦ New features – The Framework Class Libraries offer a much richer set of features, with extensive support for data access (in ADO.NET), XML, cryptography, security and much more besides. ♦ Security – The memory that a piece of code can access has more restrictions and is controlled by the CLR, thus making malicious memory accesses more difficult. The CLR also has a comprehensive security model which is integrated into the operating system making it possible to do things like prohibiting unapproved code from executing. ♦ Deployment and Management – .NET allows applications to be deployed in a choice of ways and has better features for build & deployment, version management and application configuration.
3.6
Adopt full Object-Orientation (OO)
C#.NET and VB.NET are both fully Object-Oriented languages with many powerful ObjectOrientation features that give them the advantage over the “Object-based” VB6.0 and even the .NETcompliant, but non-OO languages. A non-OO legacy language such as COBOL is not as functionally rich as VB.NET or C#.NET and so migrating an application written in that language to an ObjectOriented .NET language may offer scope for extension and improvement along Object-Orientation lines whereas this would have been impossible to do by maintaining the application in the legacy (albeit .NET-compliant) language. Adopting an Object-Oriented language therefore allows the utilization of associated ObjectOrientation design principles and developing code that has been designed with the principles of Object-Orientation in mind means that the code is more likely to be reusable. This in turn reduces development costs and means that code that is developed in this modular fashion is much easier to
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 6 of 17
maintain over time. It is not unknown for 65%+ of “boiler plate” code to be eliminated when armed with all the Object-Orientation features of the .NET Framework.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 7 of 17
4.
4.1
KEY DECISIONS
The Main Decision
Notwithstanding all the above arguments for migration, an organisation may still decide that it is happy to leave its stable and working COM/VB applications as they are. However, assuming that an organisation is convinced of the business case for migration and wishes to adopt the .NET Framework, there are a number of further key decisions to be made in order to progress. The following sections consider these.
4.2
A Language of Choice
An organisation that has decided to migrate an application or set of applications to the .NET Framework will probably want to decide on a single .NET language as the preferred language for all code produced. Despite the fact that all .NET languages are considered equal, can be freely mixed and interoperate easily, it makes sense to standardise on a single language in order to minimise training and support costs and to maximise the effectiveness of developers in maintaining and extending .NET codebases. For an organisation with a strong investment in VB skills, the selection of VB.NET as language of choice would seem to be an obvious one. Developers familiar with the Visual Basic language in its COM incarnation will recognise almost all the elements of the language in its VB.NET guise. Despite this, many organisations with a large VB codebase and communities of experienced VB developers give serious consideration to adopting C#.NET as their language of choice when moving to the .NET platform. Some of the reasons for this are matters of preference or perception whilst others lie in the fact that although VB.NET now provides support for full Object-Orientation and offers stricter type enforcement than VB did in the past, it does not actually enforce their use. What is more VB.NET continues to provide implicit conversions behind the scenes in the name of ease of use which many developers see as a deficiency and potentially dangerous. Consider the following VB.NET code: Dim evaluateString As String If evaluateString Is Nothing Then Console.WriteLine("evaluateString is Nothing") End If If evaluateString = "" Then Console.WriteLine("evaluateString is an empty string") End If Ambiguously, even with Option Strict On, both tests in the above code will evaluate as true. In addition to strong type enforcement, C#.NET benefits from several compile-time code-checking features. For example, C# code that attempts to access un-initialised variables, code that never uses a variable, (initialised or not), or code that is unreachable will all generate errors or warnings from the compiler. In comparison, VB.NET silently compiles this kind of code making it potentially more prone to errors. More subjectively, many developers see C#.NET, C++.NET and J#.NET as more syntactically elegant languages and in comparison find VB.NET syntax ugly and cumbersome. Whilst this may be a matter of personal taste, it can also be seen as indicative of a more general perception of VB.NET as the less “serious” programming language. Certainly the language enhancements planned for the next release of the .NET Framework would seem to reinforce this perception, with VB.NET language enhancements aimed at making code development easier and C#.NET enhancements aimed at making the language richer and more powerful.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 8 of 17
So does that make a convincing case for abandoning VB in the migration to .NET? Well not necessarily. There are other considerations to be taken account of, not least the comfort and familiarity factors of moving from VB6.0 to VB.NET and the preservation of existing training investment made by an organisation in the VB language. At Charteris we have adopted C#.NET as our language of choice and much of Microsoft’s own code development is now done in the language, but an organisation’s choice of .NET platform language must be based on its own circumstances, requirements and existing investment in developers and training.
4.3
How to re-skill
It is normally the case that an application developed in VB6.0 or an earlier version will be supported by some or all of those developers who produced the original code. And it is also normally the case that when the time comes, these same developers will be the team charged with migrating the application to .NET. This makes sense since they are the ones with the understanding and domain knowledge required to do it. However, if these domain experts are new to .NET or are unfamiliar with Object-Orientation (OO) design principles, problems may be experienced when attempting to migrate to the .NET Framework from the merely Object-Centric world of earlier versions of Visual Basic. Opportunities to take advantage of .NET features may be missed, there may be the temptation to bring ‘bad habits’ from the old VB world and impose them on the .NET world or developers may not know where to find useful implementations of standard functionality implemented in the Framework Class Libraries and waste time producing their own unnecessary code. It is therefore critical that an organisation takes into consideration the skills of their developers and the budget available to retrain them when choosing how to migrate to the .NET Framework. Where necessary, putting in place experts to help mentor existing staff is an extremely effective way of seeding the required skills into an organisation. This mentoring can help steer migrating developers down the right paths in adopting good practices and coding discipline for the .NET world.
4.4
Type of Migration – Porting and Re-factoring
Once an organisation 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. An organisation can essentially choose either to port the code into the .NET Framework without making any changes to the underlying solution design or to completely re-design the legacy solution and implement it in the .NET Framework. A port, as the name suggests, is an attempt at a direct line for line re-write, replicating the internal architecture and implementation of the solution and producing the same functionality and features. The appeal of taking this approach is the promise of a quick, automated (as far as possible), low resource (development, test, etc.) conversion. Re-factoring does not attempt to convert the existing code but rather takes the current logical and architectural design as a starting point for reworking the solution with Object-Orientation and the .NET Framework in mind. This ultimately leads to a new design which is then implemented in new code. The appeal of this approach is its promise of producing a better, Object Oriented and .NETcentric, design and codebase that can form the basis of future extension and enhancement. The next section examines each of these approaches in more detail and looks at the pros and cons associated with them.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 9 of 17
5.
5.1
PORTING TO THE .NET FRAMEWORK
Preparation
Preparatory work for porting concentrates on assessing the suitability of the codebase for porting and on identifying problem areas where 1-for-1 code conversion will not be possible – for example in the case of old VB “OnError-GoTo” style error handling. These situations will require intervention with some redesign and code rework and examining the codebase 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 codebase 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. Some older VB constructs and concepts that cannot be converted to VB.NET, for example control arrays, may be retained and supported by implementation of calls to VB6.0 compatibility COM libraries through wrapper .NET classes. This is the most basic port requiring the least time and effort to complete. There currently is no upgrade wizard for upgrading VB6.0 code directly to C#.NET.
5.3
Porting Manually
In the cases where developers responsible for porting code do not want to use the VB Upgrade Wizard, (or cannot use it because they are not migrating to VB.NET), 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”.
5.4
Target Language
Whilst the factors affecting the choice of .NET language have already been discussed earlier in this document it is worth revisiting the topic of the choice of .NET language again here with particular regard to porting applications. At Charteris our experience has shown that the effort involved in porting applications from VB6.0 does not vary greatly with the choice of target .NET language. We have found that the majority of the migration effort lies in the selection of the appropriate .NET Framework Class Library functionality and its use in code rather than in the mechanics of changing or adapting code syntax per se. In terms of porting at least, this makes the option of converting from VB6.0 to VB.NET (using the Upgrade Wizard if required) and then on to C#.NET at a later date, a viable option. We have found that making syntax changes going from VB.NET code to C#.NET code is often negligible when compared with the time taken by developers learning the .NET Framework Class Libraries and adapting code to use them.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 10 of 17
5.5
Pros
The 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 advice and 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 finalisation and data access. In principle the code produced will require less testing and review because of its closeness to the original codebase and the fact that much of the ported code continues to use VB compatibility DLLs means that the emphasis is on safety and workability.
5.6
Cons
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. For example, retaining the use of ADO libraries through interoperability is considerably less efficient than changing code to make use of ADO.NET. The resulting codebase 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 codebase further into the .NET world when the time comes for extending and enhancing the applications created. 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 such as better web enablement or support for Object-Orientation. Many have found that a porting exercise that retains a large amount of, and reliance on, COM interoperability and compatibility libraries represents a poor return on investment.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 11 of 17
6.
6.1
RE-FACTORING WITH THE .NET FRAMEWORK
Preparation
Re-factoring an application involves a much greater understanding of its design and implementation than would be required to port it. 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. It is obviously preferable that this design documentation exists already as collateral from the original design and implementation of the system. However, in the real world, preparation work for re-factoring may require system analysis and documentation for systems where it doesn’t already exist or is no longer as built due to documentation not being synchronised with post development enhancements. One of the goals in redesigning a VB6.0 solution and re-implementing it in the .NET Framework, is to realise 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 realising much greater long term benefits. In addition to a good understanding of the existing system, re-factoring requires expertise in ObjectOrientation design and best practice. Where an organisation does not have these skills in-house it will have to recruit people with these skills, retrain existing staff or identify short-term contract resource to provide them. 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.
6.2
Target Language
Whilst in the case of porting, the availability of the VB Upgrade Wizard might be seen as a reason for sticking with a form of the Visual Basic syntax (at least for the process of migration), there is no such attachment to VB in the case of re-factoring. As the system will be re-implemented in new code the slate is effectively clean and the choice of target language can be made with a consideration of other factors such as an organisation’s general strategy for .NET, and a view to the longer term directions that .NET languages might take.
6.3
Pros
Re-factoring is a chance to make a break from the older world of VB and COM and realise 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 COM and 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 bad practices of the past that might have been forced upon developers by the limitations of VB6.0 and earlier can be left behind and the freedom to exploit the Object-Orientation offered by .NET languages fully embraced.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 12 of 17
6.4
Cons
The goal of escaping the world of COM and older VB may not be fully realisable 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. Acquiring or developing Object-Orientation skills and .NET expertise can represent a considerable short term cost and introduce project “ramp-up” delays that an organisation may not be able or willing to accept in return for promised longer term benefits. With an effective re-design of a system there will be the temptation to take advantage of the situation to introduce new functionality. Many organisations 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 behaviours 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 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 13 of 17
7.
7.1
REAL WORLD MIGRATION
Migration Paths
As stated before, in the real world an actual migration activity for a system is likely to involve a combination or blend 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.
Decide on porting extent
Modify VB6 code. (exception handling etc.)
Use the built-in conversion tool to transfer code.
1
Completed:- limited port using VB6 libraries in .NET
re-work libraries
Use conversion tools to create C# code.
2
Completed:- VB.NET port using .NET libraries
3
Completed:- C# port using .NET libararies.
In the above example of a Visual Basic migration path there are three possible exit points from the process: 1. Here the migration activity ends after the most basic of porting activities using the VB Upgrade Wizard after any (optional) preparatory parsing of the codebase for efficient processing by the wizard. It is the fastest and least demanding of approaches but carries many of the risks described in section 5.6 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 backwards 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; all the Framework calls are however, new. 3. Here a further stage is added after the two above, to convert the syntax to C#.NET. This allows the organisation 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. Additionally, the mechanistic nature of converting VB.NET syntax to C#.NET syntax allows for the use of either in-house developed macros or the use of third-party tools to automate all or a large part of the process. Whilst these tools are not 100% effective and creating or obtaining them may represent an additional
7 September 2004 Version 1.0 Moving from Visual Basic 6.0 to .NET Charteris White Paper Page 14 of 17
cost, they may prove cost effective in getting the last part of the way to moving legacy VB applications to a C# .NET codebase. For examples of the possibilities available for such automation see The Code Project (http://www.codeproject.com/csharp/GBVB.asp) and ELLKAY (http://www.ellkay.com/ConvertVB2CSharp.htm).
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 15 of 17
8.
8.1
MANAGING MIGRATION ACTIVITIES
Operational Considerations
Here we discuss some of the control and management issues around migration that affect the successful migration of systems to .NET.
8.2
Budgetary Constraints
A key factor when considering approaches to migration is likely to be cost constraint. Re-factoring is by nature a longer and more costly process than porting and decisions to concentrate on one over the other and to vary the ratio between them in a blended solution will be affected by budget considerations. Re-factoring also brings associated risks that costs may escalate through scope-creep and the effect of re-design and re-work on other systems. Strict definition and management of scope and impact on other systems can mitigate these, but re-factoring will always remain more expensive and time-consuming than porting.
8.3
Control and Boundary Definition
As mentioned before, often systems that are being migrated will have to co-exist and interoperate with others that cannot be migrated and cannot change their interfaces. Identifying these systems early and planning for the impact of accommodating them is essential. Taking a consistent approach to interfacing to them and having the interfaces defined from the outset will aid control and containment of the effort required to interact with them. If these interfaces are common ones that other migrating systems will also use then a consistent approach will allow reuse of interoperability code modules and a common approach to interacting with them that will pay dividends in development and test effort.
8.4
Technical Issues
The move from the COM world to the .NET world presents some large architectural shifts that have an impact on both porting and re-factoring activities; the move from a reference-counted object/memory management model to a garbage-collected one presents situations where some refactoring is inescapable. In these cases a porting approach must be managed to ensure that re-factoring is limited to unavoidable re-work and does not widen its scope to include a more general re-factoring with resulting increase in cost and timescales. Whether porting or re-factoring, the move to the .NET work does not automatically bring the technology benefits of its richer feature set. Control and enforcement of good practices through teamleading and mentoring by experienced .NET professionals can avoid unnecessary and ill-advised replication of code-solutions and deprecated practices developed in the VB/COM world and can ensure that good Object-Orientation principles are adopted.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 16 of 17
9.
CONCLUSIONS
It is clear that the move from VB to .NET 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. Additionally an organisation must ask itself why it is considering migration and what it hopes to achieve from the process. Taking a simple and least disruptive approach may not yield many benefits over leaving applications un-migrated, but could potentially allow access to important features only available through .NET. Engaging in a full re-factoring exercise may leave an organisation with a welldesigned and structured codebase ready for further enhancement and reuse (through new delivery channels and integration with other .NET developed systems), but may incur unexpected costs and impact much more than the systems being migrated. The process should not be undertaken lightly and its management and control are key to successfully moving to the .NET environment and enjoying the benefits of Microsoft’s newer technology.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 17 of 17
Moving from Visual Basic 6.0 to .NET
Version 1.0 Gordon Mackie ([email protected]) 23 August 2004
©2004 Charteris plc
1. 2. 2.1 2.2 2.3 3. 3.1 3.2 3.3 3.4 3.5 3.6 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 5.5 5.6 6. 6.1 6.2 6.3 6.4 7. 7.1 8. 8.1 8.2 8.3 8.4 9.
INTRODUCTION AN OVERVIEW OF .NET What is .NET? The .NET Framework Developing in .NET THE BUSINESS CASE FOR MIGRATION “If it ain’t broke…” Increased Productivity and Reduced Maintenance Costs Increased supportability Web enablement Take advantage of the additional features of .NET Adopt full Object-Orientation (OO) KEY DECISIONS The Main Decision A Language of Choice How to re-skill Type of Migration – Porting and Re-factoring PORTING TO THE .NET FRAMEWORK Preparation The VB Upgrade Wizard Porting Manually Target Language Pros Cons RE-FACTORING WITH THE .NET FRAMEWORK Preparation Target Language Pros Cons REAL WORLD MIGRATION Migration Paths MANAGING MIGRATION ACTIVITIES Operational Considerations Budgetary Constraints Control and Boundary Definition Technical Issues CONCLUSIONS
3 4 4 4 4 5 5 5 5 5 6 6 8 8 8 9 9 10 10 10 10 10 11 11 12 12 12 12 13 14 14 16 16 16 16 16 17
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 2 of 17
1.
INTRODUCTION
Many organisations have already adopted, or are currently considering adopting, the .NET Framework as their platform of choice for strategic software development. One of the reasons often given for the move is that use of the .NET Framework protects investment in existing software development language skills such as Visual Basic and C++. The argument put forward is that if the NET framework continues to support these programming languages then developers of new projects based upon .NET will have a flying start through use of programming languages with which they are already familiar. Likewise many consider it must be a fast-track for those moving old code to the new platform as the same programming languages are used in both environments. However, in the real world, new versions of languages and new platforms on which they are implemented, present significant challenges to those adopting these newer technologies both for new development and for migration of existing applications. This Charteris White Paper examines some of the issues associated with migrating applications from Microsoft Visual Basic 6.0 (VB6.0), and earlier versions of COM-based Visual Basic, to Microsoft .NET languages including Visual Basic .NET (VB.NET). It examines the options for migration and offers some guidelines on best practices that can help organisations to successfully migrate their applications to the .NET world. For clarity in this document, we make the distinction between the concepts of porting and re-factoring in discussing the process of migrating software applications. We define porting as the process of taking COM-based VB 6.0 or earlier code and converting it to .NET code without changing the basic architecture or design. We define re-factoring as re-working a software solution in the process of moving it from COM-based VB 6.0 or earlier code to .NET code such that its feature set and functionality are retained, but that its internal implementation may be significantly different. In later sections we look at the issues involved both in porting code and in re-factoring solutions.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 3 of 17
2.
2.1
AN OVERVIEW OF .NET
What is .NET?
Microsoft defines .NET as “a set of Microsoft software technologies for connecting information, people, systems, and devices. It enables a high level of software integration through the use of Web services—small, discrete, building-block applications that connect to each other as well as to other, larger applications over the Internet.” Whilst Microsoft has in the past sought to brand (and re-brand) much of their software product set under the general umbrella of .NET, the true newer technologies that constitute .NET as far as the software development community is concerned are: ♦ The .NET Framework, which is used for building and running all kinds of software, including Web-based applications, smart client applications, and XML Web services. ♦ Developer tools, such as Microsoft Visual Studio® .NET 2003 which provides an Integrated Development Environment (IDE) for maximizing developer productivity with the .NET Framework.
2.2
The .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 than ever before to build, deploy, and administer secure, robust, and highperforming applications. The .NET Framework is composed of the Common Language Runtime (CLR) and a unified set of class libraries.
2.3
Developing in .NET
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.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 4 of 17
3.
3.1
THE BUSINESS CASE FOR MIGRATION
“If it ain’t broke…”
Whilst adopting .NET as a platform for new development projects can be seen as a relatively straightforward strategic decision on the part of an enterprise, the migration of existing applications to the .NET environment might be seen as a more questionable one. Systems that have already been developed and implemented using tools and technologies from the world of COM and which are performing their functions quite satisfactorily do not necessarily have to be moved to the .NET world. The old adage that: “if it ain’t broke, don’t fix it” could quite easily apply were it not for some arguments for migration that in many cases are compelling. The following sections examine these.
3.2
Increased Productivity and Reduced Maintenance Costs
Probably the biggest advantage offered by .NET is that much of the code that would previously have had to have been written on a bespoke basis can now be considered as “part of the plumbing” provided by .NET. No longer does the programmer need to write a mass of code to cope with, for example, memory management and garbage collection but instead s/he can focus their skills on developing business logic to meet the business need. The impact of this is that programmers are typically far more productive in delivering finished product. The corollary of having the development team focus on producing code focussed on the core business logic is that there is less code to go wrong: the infrastructure provided by .NET has been tested and is supported by Microsoft and hence is not going to need to expensive attention usually required for bespoke code. As .NET is still relatively new the skill base is still growing and hence there is a premium on hiring people with .NET skills. However, over time more and more developers will become skilled in the .NET languages such as VB.NET and C#.NET. After taking the costs associated with using one-off conversion tools in to consideration, the cost of skilled resource to perform development and maintenance tasks will soon correspond to that for the older environments. When combined with the increased productivity and the reduced maintenance costs the overall cost advantage in using .NET is significant.
3.3
Increased supportability
There is a risk in not adopting .NET. As .NET has gained significant momentum in the development community there will be fewer and fewer developers available with the skills or inclination to work with older languages. This will mean that writing code for new applications or maintaining older ones in the older codebases, will become more expensive and harder to resource. This risk is compounded by the fact that Microsoft will ramp down support for VB6.0 in 2005. So migrating to .NET will reduce the risk of being dependent upon a disappearing Microsoft product support structure. With progressively fewer developers available to support VB6.0 applications in the future, migrating to .NET means that business-critical applications will continue to enjoy support for the underlying technologies from Microsoft. One could argue that the same may happen to .NET as is now happening to VB6.0. However, this is unlikely as Microsoft have already announced that the roadmap for the next generation of their operating systems (codenamed Longhorn) will have an integral component - WinFX, which will extend V2.0 of the .NET Framework incorporated in Visual Studio 2005 (due to be released next year), adding APIs for a new graphical user interface subsystem (Avalon), a new file subsystem (WinFS) and a new Web Services messaging subsystem (Indigo). Hence, one can be confident that the approach to future developments is more one of evolution rather than the distinct shift that we have seen with the introduction of .NET.
3.4
Web enablement
Although web development was, and is, possible using the COM-based technologies in VB6.0 and earlier versions of Visual Basic, such capabilities were add-ons to the core functionality and not built-in
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 5 of 17
to the heart of their structure and operation. In contrast, the .NET Framework is oriented very much towards using the internet and its associated messaging protocols as the preferred way of developing and integrating applications. The .NET Framework is essentially designed bottom-up to support fast-emerging standards such as the Simple Object Access Protocol (SOAP) which allow applications to communicate with each other across networks and the internet using XML Web Services. Migrating to the .NET Framework means that these standards can be embedded by default into the applications that organisations write, increasing their ability to communicate with external applications.
3.5
Take advantage of the additional features of .NET
There are many key benefits and improvements that the .NET Framework provides over VB6.0, these include: ♦ Stability – .NET is not prone to the memory leak problems often encountered in the COM world. Because the .NET Framework is type-safe and uses the in-built Garbage Collector to reclaim memory, memory allocation and release is no longer the responsibility of the applications developer, nor of the developers of any libraries s/he uses. Additionally, the .NET assemblies have greater control over mutual component-compatibility levels eliminating many problems with deployed libraries of mismatched versions. ♦ Better organisation – The Framework Class Libraries offer a well structured and documented set of features, organised into logical namespaces. These are accessible to all .NET languages and provide a better coding model than that of older Visual Basic versions with their inconsistent use of keywords, object-references and API declarations to extend and enhance language functionality. Developers can take advantage of namespaces too, for organisation and logical grouping of their own code. ♦ Better inline documentation – In C# .NET, XML documentation offers the ability to add rich code annotation that can be used to generate help documentation and intellisense for code artefacts. VB.NET will have XML documentation in the next release of Visual Studio (Visual Studio.NET 2005) and third-party add-ins are available that emulate it in the current version. ♦ New features – The Framework Class Libraries offer a much richer set of features, with extensive support for data access (in ADO.NET), XML, cryptography, security and much more besides. ♦ Security – The memory that a piece of code can access has more restrictions and is controlled by the CLR, thus making malicious memory accesses more difficult. The CLR also has a comprehensive security model which is integrated into the operating system making it possible to do things like prohibiting unapproved code from executing. ♦ Deployment and Management – .NET allows applications to be deployed in a choice of ways and has better features for build & deployment, version management and application configuration.
3.6
Adopt full Object-Orientation (OO)
C#.NET and VB.NET are both fully Object-Oriented languages with many powerful ObjectOrientation features that give them the advantage over the “Object-based” VB6.0 and even the .NETcompliant, but non-OO languages. A non-OO legacy language such as COBOL is not as functionally rich as VB.NET or C#.NET and so migrating an application written in that language to an ObjectOriented .NET language may offer scope for extension and improvement along Object-Orientation lines whereas this would have been impossible to do by maintaining the application in the legacy (albeit .NET-compliant) language. Adopting an Object-Oriented language therefore allows the utilization of associated ObjectOrientation design principles and developing code that has been designed with the principles of Object-Orientation in mind means that the code is more likely to be reusable. This in turn reduces development costs and means that code that is developed in this modular fashion is much easier to
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 6 of 17
maintain over time. It is not unknown for 65%+ of “boiler plate” code to be eliminated when armed with all the Object-Orientation features of the .NET Framework.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 7 of 17
4.
4.1
KEY DECISIONS
The Main Decision
Notwithstanding all the above arguments for migration, an organisation may still decide that it is happy to leave its stable and working COM/VB applications as they are. However, assuming that an organisation is convinced of the business case for migration and wishes to adopt the .NET Framework, there are a number of further key decisions to be made in order to progress. The following sections consider these.
4.2
A Language of Choice
An organisation that has decided to migrate an application or set of applications to the .NET Framework will probably want to decide on a single .NET language as the preferred language for all code produced. Despite the fact that all .NET languages are considered equal, can be freely mixed and interoperate easily, it makes sense to standardise on a single language in order to minimise training and support costs and to maximise the effectiveness of developers in maintaining and extending .NET codebases. For an organisation with a strong investment in VB skills, the selection of VB.NET as language of choice would seem to be an obvious one. Developers familiar with the Visual Basic language in its COM incarnation will recognise almost all the elements of the language in its VB.NET guise. Despite this, many organisations with a large VB codebase and communities of experienced VB developers give serious consideration to adopting C#.NET as their language of choice when moving to the .NET platform. Some of the reasons for this are matters of preference or perception whilst others lie in the fact that although VB.NET now provides support for full Object-Orientation and offers stricter type enforcement than VB did in the past, it does not actually enforce their use. What is more VB.NET continues to provide implicit conversions behind the scenes in the name of ease of use which many developers see as a deficiency and potentially dangerous. Consider the following VB.NET code: Dim evaluateString As String If evaluateString Is Nothing Then Console.WriteLine("evaluateString is Nothing") End If If evaluateString = "" Then Console.WriteLine("evaluateString is an empty string") End If Ambiguously, even with Option Strict On, both tests in the above code will evaluate as true. In addition to strong type enforcement, C#.NET benefits from several compile-time code-checking features. For example, C# code that attempts to access un-initialised variables, code that never uses a variable, (initialised or not), or code that is unreachable will all generate errors or warnings from the compiler. In comparison, VB.NET silently compiles this kind of code making it potentially more prone to errors. More subjectively, many developers see C#.NET, C++.NET and J#.NET as more syntactically elegant languages and in comparison find VB.NET syntax ugly and cumbersome. Whilst this may be a matter of personal taste, it can also be seen as indicative of a more general perception of VB.NET as the less “serious” programming language. Certainly the language enhancements planned for the next release of the .NET Framework would seem to reinforce this perception, with VB.NET language enhancements aimed at making code development easier and C#.NET enhancements aimed at making the language richer and more powerful.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 8 of 17
So does that make a convincing case for abandoning VB in the migration to .NET? Well not necessarily. There are other considerations to be taken account of, not least the comfort and familiarity factors of moving from VB6.0 to VB.NET and the preservation of existing training investment made by an organisation in the VB language. At Charteris we have adopted C#.NET as our language of choice and much of Microsoft’s own code development is now done in the language, but an organisation’s choice of .NET platform language must be based on its own circumstances, requirements and existing investment in developers and training.
4.3
How to re-skill
It is normally the case that an application developed in VB6.0 or an earlier version will be supported by some or all of those developers who produced the original code. And it is also normally the case that when the time comes, these same developers will be the team charged with migrating the application to .NET. This makes sense since they are the ones with the understanding and domain knowledge required to do it. However, if these domain experts are new to .NET or are unfamiliar with Object-Orientation (OO) design principles, problems may be experienced when attempting to migrate to the .NET Framework from the merely Object-Centric world of earlier versions of Visual Basic. Opportunities to take advantage of .NET features may be missed, there may be the temptation to bring ‘bad habits’ from the old VB world and impose them on the .NET world or developers may not know where to find useful implementations of standard functionality implemented in the Framework Class Libraries and waste time producing their own unnecessary code. It is therefore critical that an organisation takes into consideration the skills of their developers and the budget available to retrain them when choosing how to migrate to the .NET Framework. Where necessary, putting in place experts to help mentor existing staff is an extremely effective way of seeding the required skills into an organisation. This mentoring can help steer migrating developers down the right paths in adopting good practices and coding discipline for the .NET world.
4.4
Type of Migration – Porting and Re-factoring
Once an organisation 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. An organisation can essentially choose either to port the code into the .NET Framework without making any changes to the underlying solution design or to completely re-design the legacy solution and implement it in the .NET Framework. A port, as the name suggests, is an attempt at a direct line for line re-write, replicating the internal architecture and implementation of the solution and producing the same functionality and features. The appeal of taking this approach is the promise of a quick, automated (as far as possible), low resource (development, test, etc.) conversion. Re-factoring does not attempt to convert the existing code but rather takes the current logical and architectural design as a starting point for reworking the solution with Object-Orientation and the .NET Framework in mind. This ultimately leads to a new design which is then implemented in new code. The appeal of this approach is its promise of producing a better, Object Oriented and .NETcentric, design and codebase that can form the basis of future extension and enhancement. The next section examines each of these approaches in more detail and looks at the pros and cons associated with them.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 9 of 17
5.
5.1
PORTING TO THE .NET FRAMEWORK
Preparation
Preparatory work for porting concentrates on assessing the suitability of the codebase for porting and on identifying problem areas where 1-for-1 code conversion will not be possible – for example in the case of old VB “OnError-GoTo” style error handling. These situations will require intervention with some redesign and code rework and examining the codebase 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 codebase 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. Some older VB constructs and concepts that cannot be converted to VB.NET, for example control arrays, may be retained and supported by implementation of calls to VB6.0 compatibility COM libraries through wrapper .NET classes. This is the most basic port requiring the least time and effort to complete. There currently is no upgrade wizard for upgrading VB6.0 code directly to C#.NET.
5.3
Porting Manually
In the cases where developers responsible for porting code do not want to use the VB Upgrade Wizard, (or cannot use it because they are not migrating to VB.NET), 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”.
5.4
Target Language
Whilst the factors affecting the choice of .NET language have already been discussed earlier in this document it is worth revisiting the topic of the choice of .NET language again here with particular regard to porting applications. At Charteris our experience has shown that the effort involved in porting applications from VB6.0 does not vary greatly with the choice of target .NET language. We have found that the majority of the migration effort lies in the selection of the appropriate .NET Framework Class Library functionality and its use in code rather than in the mechanics of changing or adapting code syntax per se. In terms of porting at least, this makes the option of converting from VB6.0 to VB.NET (using the Upgrade Wizard if required) and then on to C#.NET at a later date, a viable option. We have found that making syntax changes going from VB.NET code to C#.NET code is often negligible when compared with the time taken by developers learning the .NET Framework Class Libraries and adapting code to use them.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 10 of 17
5.5
Pros
The 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 advice and 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 finalisation and data access. In principle the code produced will require less testing and review because of its closeness to the original codebase and the fact that much of the ported code continues to use VB compatibility DLLs means that the emphasis is on safety and workability.
5.6
Cons
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. For example, retaining the use of ADO libraries through interoperability is considerably less efficient than changing code to make use of ADO.NET. The resulting codebase 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 codebase further into the .NET world when the time comes for extending and enhancing the applications created. 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 such as better web enablement or support for Object-Orientation. Many have found that a porting exercise that retains a large amount of, and reliance on, COM interoperability and compatibility libraries represents a poor return on investment.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 11 of 17
6.
6.1
RE-FACTORING WITH THE .NET FRAMEWORK
Preparation
Re-factoring an application involves a much greater understanding of its design and implementation than would be required to port it. 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. It is obviously preferable that this design documentation exists already as collateral from the original design and implementation of the system. However, in the real world, preparation work for re-factoring may require system analysis and documentation for systems where it doesn’t already exist or is no longer as built due to documentation not being synchronised with post development enhancements. One of the goals in redesigning a VB6.0 solution and re-implementing it in the .NET Framework, is to realise 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 realising much greater long term benefits. In addition to a good understanding of the existing system, re-factoring requires expertise in ObjectOrientation design and best practice. Where an organisation does not have these skills in-house it will have to recruit people with these skills, retrain existing staff or identify short-term contract resource to provide them. 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.
6.2
Target Language
Whilst in the case of porting, the availability of the VB Upgrade Wizard might be seen as a reason for sticking with a form of the Visual Basic syntax (at least for the process of migration), there is no such attachment to VB in the case of re-factoring. As the system will be re-implemented in new code the slate is effectively clean and the choice of target language can be made with a consideration of other factors such as an organisation’s general strategy for .NET, and a view to the longer term directions that .NET languages might take.
6.3
Pros
Re-factoring is a chance to make a break from the older world of VB and COM and realise 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 COM and 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 bad practices of the past that might have been forced upon developers by the limitations of VB6.0 and earlier can be left behind and the freedom to exploit the Object-Orientation offered by .NET languages fully embraced.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 12 of 17
6.4
Cons
The goal of escaping the world of COM and older VB may not be fully realisable 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. Acquiring or developing Object-Orientation skills and .NET expertise can represent a considerable short term cost and introduce project “ramp-up” delays that an organisation may not be able or willing to accept in return for promised longer term benefits. With an effective re-design of a system there will be the temptation to take advantage of the situation to introduce new functionality. Many organisations 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 behaviours 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 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 13 of 17
7.
7.1
REAL WORLD MIGRATION
Migration Paths
As stated before, in the real world an actual migration activity for a system is likely to involve a combination or blend 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.
Decide on porting extent
Modify VB6 code. (exception handling etc.)
Use the built-in conversion tool to transfer code.
1
Completed:- limited port using VB6 libraries in .NET
re-work libraries
Use conversion tools to create C# code.
2
Completed:- VB.NET port using .NET libraries
3
Completed:- C# port using .NET libararies.
In the above example of a Visual Basic migration path there are three possible exit points from the process: 1. Here the migration activity ends after the most basic of porting activities using the VB Upgrade Wizard after any (optional) preparatory parsing of the codebase for efficient processing by the wizard. It is the fastest and least demanding of approaches but carries many of the risks described in section 5.6 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 backwards 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; all the Framework calls are however, new. 3. Here a further stage is added after the two above, to convert the syntax to C#.NET. This allows the organisation 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. Additionally, the mechanistic nature of converting VB.NET syntax to C#.NET syntax allows for the use of either in-house developed macros or the use of third-party tools to automate all or a large part of the process. Whilst these tools are not 100% effective and creating or obtaining them may represent an additional
7 September 2004 Version 1.0 Moving from Visual Basic 6.0 to .NET Charteris White Paper Page 14 of 17
cost, they may prove cost effective in getting the last part of the way to moving legacy VB applications to a C# .NET codebase. For examples of the possibilities available for such automation see The Code Project (http://www.codeproject.com/csharp/GBVB.asp) and ELLKAY (http://www.ellkay.com/ConvertVB2CSharp.htm).
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 15 of 17
8.
8.1
MANAGING MIGRATION ACTIVITIES
Operational Considerations
Here we discuss some of the control and management issues around migration that affect the successful migration of systems to .NET.
8.2
Budgetary Constraints
A key factor when considering approaches to migration is likely to be cost constraint. Re-factoring is by nature a longer and more costly process than porting and decisions to concentrate on one over the other and to vary the ratio between them in a blended solution will be affected by budget considerations. Re-factoring also brings associated risks that costs may escalate through scope-creep and the effect of re-design and re-work on other systems. Strict definition and management of scope and impact on other systems can mitigate these, but re-factoring will always remain more expensive and time-consuming than porting.
8.3
Control and Boundary Definition
As mentioned before, often systems that are being migrated will have to co-exist and interoperate with others that cannot be migrated and cannot change their interfaces. Identifying these systems early and planning for the impact of accommodating them is essential. Taking a consistent approach to interfacing to them and having the interfaces defined from the outset will aid control and containment of the effort required to interact with them. If these interfaces are common ones that other migrating systems will also use then a consistent approach will allow reuse of interoperability code modules and a common approach to interacting with them that will pay dividends in development and test effort.
8.4
Technical Issues
The move from the COM world to the .NET world presents some large architectural shifts that have an impact on both porting and re-factoring activities; the move from a reference-counted object/memory management model to a garbage-collected one presents situations where some refactoring is inescapable. In these cases a porting approach must be managed to ensure that re-factoring is limited to unavoidable re-work and does not widen its scope to include a more general re-factoring with resulting increase in cost and timescales. Whether porting or re-factoring, the move to the .NET work does not automatically bring the technology benefits of its richer feature set. Control and enforcement of good practices through teamleading and mentoring by experienced .NET professionals can avoid unnecessary and ill-advised replication of code-solutions and deprecated practices developed in the VB/COM world and can ensure that good Object-Orientation principles are adopted.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 16 of 17
9.
CONCLUSIONS
It is clear that the move from VB to .NET 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. Additionally an organisation must ask itself why it is considering migration and what it hopes to achieve from the process. Taking a simple and least disruptive approach may not yield many benefits over leaving applications un-migrated, but could potentially allow access to important features only available through .NET. Engaging in a full re-factoring exercise may leave an organisation with a welldesigned and structured codebase ready for further enhancement and reuse (through new delivery channels and integration with other .NET developed systems), but may incur unexpected costs and impact much more than the systems being migrated. The process should not be undertaken lightly and its management and control are key to successfully moving to the .NET environment and enjoying the benefits of Microsoft’s newer technology.
7 September 2004 Version 1.0
Moving from Visual Basic 6.0 to .NET Charteris White Paper
Page 17 of 17
