moving from visual basic 6.0 to .net

8/14/2019 Moving From Visual Basic 6.0 to .NET

1/17

2004 Charteris plc

Charteris White Paper

Moving from Visual Basic 6.0 to.NET

Version 1.0

Gordon Mackie ([email protected])

23 August 2004


2/17

7 September 2004 Version 1.0

Moving from Visual Basic 6.0 to .NETCharteris White Paper

Page 2 of 17

1. INTRODUCTION 3

2. AN OVERVIEW OF .NET 4 2.1 What is .NET? 2.2 The .NET Framework 2.3 Developing in .NET 4 3. THE BUSINESS CASE FOR MIGRATION 5 3.1 If it aint broke 5 3.2 Increased Productivity and Reduced Maintenance Costs 5 3.3 Increased supportability 5 3.4 Web enablement 3.5 Take advantage of the additional features of .NET 6 3.6 Adopt full Object-Orientation (OO) 6

4. KEY DECISIONS 8 4.1 The Main Decision 4.2 A Language of Choice 8 4.3 How to re-skill 9 4.4 Type of Migration Porting and Re-factoring 9

5. PORTING TO THE .NET FRAMEWORK 10 5.1 Preparation 10 5.2 The VB Upgrade Wizard 10 5.3 Porting Manually 10 5.4 Target Language 5.5 Pros 11 5.6 Cons 11

6. RE-FACTORING WITH THE .NET FRAMEWORK 12 6.1 Preparation 12 6.2 Target Language 6.3 Pros 12 6.4 Cons 13

7. REAL WORLD MIGRATION 14 7.1 Migration Paths 14

8. MANAGING MIGRATION ACTIVITIES 16 8.1 Operational Considerations 16 8.2 Budgetary Constraints 16 8.3 Control and Boundary Definition 16 8.4 Technical Issues

9.

CONCLUSIONS 17


3/17



Page 3 of 17

1. INTRODUCTIONMany 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 themove is that use of the .NET Framework protects investment in existing software developmentlanguage skills such as Visual Basic and C++. The argument put forward is that if the NETframework continues to support these programming languages then developers of new projects basedupon .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, presentsignificant challenges to those adopting these newer technologies both for new development and formigration of existing applications.

This Charteris White Paper examines some of the issues associated with migrating applications fromMicrosoft 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 andoffers 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 indiscussing 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 basicarchitecture 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 areretained, but that its internal implementation may be significantly different. In later sections we look atthe issues involved both in porting code and in re-factoring solutions.


4/17



Page 4 of 17

2. AN OVERVIEW OF .NET2.1 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 servicessmall, 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 setunder the general umbrella of .NET, the true newer technologies that constitute .NET as far as thesoftware 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 IntegratedDevelopment Environment (IDE) for maximizing developer productivity with the .NETFramework.

2.2 The .NET Framework The .NET Framework is an integral Windows component for building and running the nextgeneration of software applications and Web services. The .NET Framework:

Supports over 20 different programming languages with 4 core languages supplied by Microsoftnamely C#.NET, VB.NET, C++ .NET and J#.NET.

Manages much of the plumbing involved in developing software, enabling developers to focus onthe code associated with the core business logic.

Makes it easier than ever before 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.2.3 Developing in .NETDevelopers can use the .NET language of their choice for code creation and debugging. Whencompiled with a language specific compiler in the .NET Framework, the language-specific code getstranslated 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 isusually done by a just-in-time (JIT) compiler converting MSIL to native code only when actually required.


5/17



Page 5 of 17

3. THE BUSINESS CASE FOR MIGRATION3.1 If it aint 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 beendeveloped and implemented using tools and technologies from the world of COM and which areperforming their functions quite satisfactorily do not necessarily have to be moved to the .NET world.

The old adage that: if it aint broke, dont fix it could quite easily apply were it not for somearguments for migration that in many cases are compelling. The following sections examine these.

3.2 Increased Productivity and Reduced Maintenance CostsProbably the biggest advantage offered by .NET is that much of the code that would previously havehad to have been written on a bespoke basis can now be considered as part of the plumbingprovided by .NET. No longer does the programmer need to write a mass of code to cope with, forexample, memory management and garbage collection but instead s/he can focus their skills ondeveloping 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 businesslogic is that there is less code to go wrong: the infrastructure provided by .NET has been tested and issupported by Microsoft and hence is not going to need to expensive attention usually required forbespoke 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 andmaintenance tasks will soon correspond to that for the older environments. When combined with theincreased 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 developmentcommunity 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 onesin 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. Somigrating to .NET will reduce the risk of being dependent upon a disappearing Microsoft productsupport structure. With progressively fewer developers available to support VB6.0 applications in thefuture, migrating to .NET means that business-critical applications will continue to enjoy support forthe underlying technologies from Microsoft.

One could argue that the same may happen to .NET as is now happening to VB6.0. However, this isunlikely as Microsoft have already announced that the roadmap for the next generation of theiroperating 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) anda new Web Services messaging subsystem (Indigo). Hence, one can be confident that the approach tofuture developments is more one of evolution rather than the distinct shift that we have seen with theintroduction of .NET.

3.4 Web enablement Although web development was, and is, possible using the COM-based technologies in VB6.0 andearlier versions of Visual Basic, such capabilities were add-ons to the core functionality and not built-in


6/17



Page 6 of 17

to the heart of their structure and operation. In contrast, the .NET Framework is oriented very muchtowards 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 asthe 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 meansthat 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, theseinclude:

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 toreclaim memory, memory allocation and release is no longer the responsibility of the applicationsdeveloper, nor of the developers of any libraries s/he uses. Additionally, the .NET assemblies havegreater control over mutual component-compatibility levels eliminating many problems withdeployed libraries of mismatched versions.

Better organisation The Framework Class Libraries offer a well structured and documented setof features, organised into logical namespaces. These are accessible to all .NET languages andprovide a better coding model than that of older Visual Basic versions with their inconsistent useof 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 theirown code.

Better inline documentation In C# .NET, XML documentation offers the ability to add richcode annotation that can be used to generate help documentation and intellisense for codeartefacts. 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 acomprehensive security model which is integrated into the operating system making it possible todo things like prohibiting unapproved code from executing.

Deployment and Management .NET allows applications to be deployed in a choice of waysand has better features for build & deployment, version management and applicationconfiguration.

3.6 Adopt full Object-Orientation (OO)C#.NET and VB.NET are both fully Object-Oriented languages with many powerful Object-Orientation features that give them the advantage over the Object-based VB6.0 and even the .NET-compliant, 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 Object-Oriented .NET language may offer scope for extension and improvement along Object-Orientationlines 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 Object-Orientation 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 reducesdevelopment costs and means that code that is developed in this modular fashion is much easier to


7/17



Page 7 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.


8/17



Page 8 of 17

4. KEY DECISIONS4.1 The Main DecisionNotwithstanding 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 .NETFramework, there are a number of further key decisions to be made in order to progress. Thefollowing sections consider these.

4.2 A Language of Choice An organisation that has decided to migrate an application or set of applications to the .NETFramework will probably want to decide on a single .NET language as the preferred language for allcode produced. Despite the fact that all .NET languages are considered equal, can be freely mixed andinteroperate easily, it makes sense to standardise on a single language in order to minimise training andsupport costs and to maximise the effectiveness of developers in maintaining and extending .NETcodebases.

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 itsCOM incarnation will recognise almost all the elements of the language in its VB.NET guise. Despitethis, many organisations with a large VB codebase and communities of experienced VB developersgive serious consideration to adopting C#.NET as their language of choice when moving to the .NETplatform.

Some of the reasons for this are matters of preference or perception whilst others lie in the fact thatalthough VB.NET now provides support for full Object-Orientation and offers stricter typeenforcement than VB did in the past, it does not actually enforce their use. What is more VB.NETcontinues 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 thecompiler. In comparison, VB.NET silently compiles this kind of code making it potentially moreprone 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 amatter of personal taste, it can also be seen as indicative of a more general perception of VB.NET asthe less serious programming language. Certainly the language enhancements planned for the nextrelease of the .NET Framework would seem to reinforce this perception, with VB.NET languageenhancements aimed at making code development easier and C#.NET enhancements aimed at making the language richer and more powerful.


9/17



Page 9 of 17

So does that make a convincing case for abandoning VB in the migration to .NET? Well notnecessarily. There are other considerations to be taken account of, not least the comfort andfamiliarity 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 asour language of choice and much of Microsofts own code development is now done in the language,but an organisations 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-skillIt 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 knowledgerequired 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 theold VB world and impose them on the .NET world or developers may not know where to find usefulimplementations of standard functionality implemented in the Framework Class Libraries and wastetime producing their own unnecessary code.

It is therefore critical that an organisation takes into consideration the skills of their developers and thebudget available to retrain them when choosing how to migrate to the .NET Framework. Wherenecessary, 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 theright paths in adopting good practices and coding discipline for the .NET world.

4.4 Type of Migration Porting and Re-factoringOnce an organisation has taken the decision to move its legacy code to the .NET Framework, it mustdecide on its approach to the process. Although individual cases will vary and in most cases a blendedapproach 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 withoutmaking any changes to the underlying solution design or to completely re-design the legacy solutionand 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 internalarchitecture 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 andarchitectural 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 .NET-centric, 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 consassociated with them.


10/17



Page 10 of 17

5. PORTING TO THE .NET FRAMEWORK 5.1 PreparationPreparatory work for porting concentrates on assessing the suitability of the codebase for porting andon 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 withsome redesign and code rework and examining the codebase from this perspective allows anassessment the level of the rework likely and may suggest that the re-factoring approach wouldultimately 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 thecreation and insertion of standard code constructs such as error-handling and logging. It may bepossible to leverage these in order to remove or alter code before it is upgraded to reduce the time ittakes to process the code and reduce the size of the issue report it produces.

5.2 The VB Upgrade WizardMicrosoft Visual Studio .NET offers a VB upgrade wizard to assist in the migration of earlier VB codeto VB.NET. This tool attempts to convert code from VB to VB.NET, provides an upgrade reportlisting any problems encountered and annotates the converted code with comments on conversionissues 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 beconverted to VB.NET, for example control arrays, may be retained and supported by implementationof calls to VB6.0 compatibility COM libraries through wrapper .NET classes. This is the most basicport 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 ManuallyIn 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 thecode manually. Code must be examined line-by-line and converted to a .NET equivalentimplementation where possible and any unavoidable workarounds hand-coded to suit the particularcircumstances and requirements of the code being converted. Whereas the VB Upgrade Wizard mightmake 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 betterchoices 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 thisdocument it is worth revisiting the topic of the choice of .NET language again here with particularregard to porting applications.

At Charteris our experience has shown that the effort involved in porting applications from VB6.0does not vary greatly with the choice of target .NET language. We have found that the majority of themigration 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 termsof 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 withthe time taken by developers learning the .NET Framework Class Libraries and adapting code to usethem.


11/17



Page 11 of 17

5.5 Pros The VB Upgrade Wizard provides a quick and largely automated route to porting code leaving thedeveloper to fix the aspects that cannot be ported automatically using the advice and guidanceprovided 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 onunderstanding of the design than on understanding of VB and COM fundamentals such as finalisationand data access.

In principle the code produced will require less testing and review because of its closeness to theoriginal codebase and the fact that much of the ported code continues to use VB compatibility DLLsmeans 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 whichis unlikely to be the most efficient or logical. For example, retaining the use of ADO libraries throughinteroperability is considerably less efficient than changing code to make use of ADO.NET. Theresulting codebase produced by the wizard is almost always a hybrid of .NET code and calls to VBcompatibility 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 adependency on COM interoperability and older VB libraries may hamper future efforts to move thecodebase further into the .NET world when the time comes for extending and enhancing theapplications created. Additionally the reliance of older VB6.0 libraries introduces a risk for codesupport 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 notaddressed 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 .NETs new featuressuch 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, COMinteroperability and compatibility libraries represents a poor return on investment.


12/17



Page 12 of 17

6. RE-FACTORING WITH THE .NET FRAMEWORK 6.1 PreparationRe-factoring an application involves a much greater understanding of its design and implementationthan 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 designdocumentation. It is obviously preferable that this design documentation exists already as collateralfrom 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 doesntalready exist or is no longer as built due to documentation not being synchronised with postdevelopment enhancements.

One of the goals in redesigning a VB6.0 solution and re-implementing it in the .NET Framework, is torealise the benefits of Object-Orientation such as code reuse and more efficient structure. In order todo this the system must be comprehensively understood and redesigned using Object-Orientationprinciples. This analysis and design preparation obviously represents a greater short term cost andeffort than that associated with porting but carries the potential of realising much greater long termbenefits.

In addition to a good understanding of the existing system, re-factoring requires expertise in Object-Orientation design and best practice. Where an organisation does not have these skills in-house it willhave to recruit people with these skills, retrain existing staff or identify short-term contract resource toprovide them.

Where the scope of the work includes the introduction of new functionality or a fundamental designchange 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 forsticking with a form of the Visual Basic syntax (at least for the process of migration), there is no suchattachment to VB in the case of re-factoring. As the system will be re-implemented in new code theslate is effectively clean and the choice of target language can be made with a consideration of otherfactors such as an organisations general strategy for .NET, and a view to the longer term directionsthat .NET languages might take.

6.3 ProsRe-factoring is a chance to make a break from the older world of VB and COM and realise the benefitsof re-designing and implementing systems to take advantage of Object-Orientation and newertechnologies 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 oninteroperability and legacy COM and VB DLLs.

Re-factoring also represents a chance to take a pattern-based approach to re-design andimplementation that wouldnt be possible with porting common solutions to common designscenarios can be approached in terms of existing documented patterns and implemented in reusablemodules that can be applied across the system for common needs such as data-access, messagemanagement, 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.0and earlier can be left behind and the freedom to exploit the Object-Orientation offered by .NETlanguages fully embraced.


13/17



Page 13 of 17

6.4 Cons The goal of escaping the world of COM and older VB may not be fully realisable if the re-factoredsystems still have to rely on services not currently available through .NET such as distributedtransaction support or where the systems must make use of third-party integration components thatare COM based many of Microsofts 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 considerableshort 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 situationto introduce new functionality. Many organisations will build wish-lists of future requirement requestsbetween application releases and the option to roll these features into a re-factoring migration may beappealing. 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 propercontrol 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 othersystems that are not being migrated at all or are being ported rather than re-factored. There is apotential domino-effect of changes in re-factored systems interfaces or behaviours forcing changeon 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 toaccommodate the constraints that the external systems represent. At the very least problems may beencountered 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.


14/17



Page 14 of 17

7. REAL WORLD MIGRATION7.1 Migration Paths

As stated before, in the real world an actual migration activity for a system is likely to involve acombination 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.

Modify VB6 code.(exception handling etc.)

Decide on porting extent

Use the built-in conversiontool to transfer code.

re-work libraries

Completed:- VB.NET portusing .NET libraries

Use conversion tools tocreate C# code.

Completed:- limited portusing VB6 libraries in .NET

Completed:- C# port using.NET libararies.

1

2 3

In the above example of a Visual Basic migration path there are three possible exit points from theprocess:

1. Here the migration activity ends after the most basic of porting activities using the VBUpgrade Wizard after any (optional) preparatory parsing of the codebase for efficientprocessing 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 backwardscompatibility libraries; this represents a significant amount of work and needs to be donemanually 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. Thisallows the organisation to adopt C# as its language of choice if it desires and does not addsignificant overhead since the majority of the migration effort will occur at stage 2 above, inchanging 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. Whilstthese tools are not 100% effective and creating or obtaining them may represent an additional


15/17



Page 15 of 17

cost, they may prove cost effective in getting the last part of the way to moving legacy VBapplications to a C# .NET codebase. For examples of the possibilities available for suchautomation see The Code Project ( http://www.codeproject.com/csharp/GBVB.asp ) andELLKAY ( http://www.ellkay.com/ConvertVB2CSharp.htm ).


16/17



Page 16 of 17

8. MANAGING MIGRATION ACTIVITIES8.1 Operational ConsiderationsHere we discuss some of the control and management issues around migration that affect thesuccessful 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 isby nature a longer and more costly process than porting and decisions to concentrate on one over theother and to vary the ratio between them in a blended solution will be affected by budgetconsiderations. Re-factoring also brings associated risks that costs may escalate through scope-creepand the effect of re-design and re-work on other systems. Strict definition and management of scopeand impact on other systems can mitigate these, but re-factoring will always remain more expensiveand 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 withothers that cannot be migrated and cannot change their interfaces. Identifying these systems early andplanning for the impact of accommodating them is essential. Taking a consistent approach tointerfacing to them and having the interfaces defined from the outset will aid control and containmentof the effort required to interact with them.

If these interfaces are common ones that other migrating systems will also use then a consistentapproach will allow reuse of interoperability code modules and a common approach to interacting withthem 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 havean 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 re-factoring 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 thetechnology benefits of its richer feature set. Control and enforcement of good practices through team-leading and mentoring by experienced .NET professionals can avoid unnecessary and ill-advisedreplication of code-solutions and deprecated practices developed in the VB/COM world and canensure that good Object-Orientation principles are adopted.


17/17



Page 17 of 17

9. CONCLUSIONSIt 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 greatmany 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 eachapproach. In most cases the combined business/technical factors will force a blend of approaches tobe adopted.

Additionally an organisation must ask itself why it is considering migration and what it hopes toachieve from the process. Taking a simple and least disruptive approach may not yield many benefitsover 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 well-designed 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 andimpact 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 Microsofts newer technology.

moving from visual basic 6.0 to .net

Documents