Upgrading Visual Basic 6.

0
Applications to Visual Basic .NET
and Visual Basic 2005
Upgrading Visual Basic 6.0
Applications to Visual Basic .NET
and Visual Basic 2005

p a t t er ns & p ra c t i c es
ISBN 0-7356-2298-1
Information in this document, including URL and other Internet Web site
references, is subject to change without notice. Unless otherwise noted, the
example companies, organizations, products, domain names, e-mail addresses,
logos, people, places, and events depicted herein are fictitious, and no association
with any real company, organization, product, domain name, e-mail address, logo,
person, place, or event is intended or should be inferred. Complying with all
applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from Microsoft, the furnishing
of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Mobile, Windows NT, Windows Server,
ActiveX, Excel, FrontPage, IntelliSense, JScript, Visual Basic, Visual C++, Visual C#,
Visual J#, Visual Studio, and Win32 are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
ArtinSoft is the registered trademark of ArtinSoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.
Contents
Preface xv
Who Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
For Technical Decision Makers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
For Solution Architects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
For Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
How to Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Relevant Chapters for Technical Decision Makers . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Relevant Chapters for Solution Architects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Relevant Chapters for Software Developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Feedback and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Principal Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Chapter 1
Introduction 1
Why Consider an Upgrade Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Minimum Information Needed to Make a Decision . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Upgrade Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Moving from Visual Basic 6.0 to Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Increased Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Better Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Application Extendibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Improved Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Improved Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Improved Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Increased Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Benefits of the Visual Basic 6.0 to Visual Basic .NET Upgrade Wizard . . . . . . . . . . . 23
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 2
Practices for Successful Upgrades 25
Functional Equivalence and Application Advancement . . . . . . . . . . . . . . . . . . . . . . . . . 25
Functional Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Application Advancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iv Contents

Organizational Structure and the Software Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 26

Overview of the Upgrade Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Proof of Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Planning the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Defining the Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Performing an Application Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Assessing the Current and the Target Architectures . . . . . . . . . . . . . . . . . . . . . . . . 33
Analyzing and Designing New Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Selecting an Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Making an Inventory of Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Preparing the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Preparing to Handle Upgrade Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Producing a Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Estimating Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Preparing for the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Preparing the Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Preparing the Visual Basic 6.0 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Upgrading Applications Written in Earlier Versions of Visual Basic . . . . . . . . . . . . . . 50
Verifying Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Upgrading the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Testing and Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Microsoft Windows Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Advancing an Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Managing an Upgrade Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Managing the Project after Using the Upgrade Wizard . . . . . . . . . . . . . . . . . . . . . . . 59
Upgrade Project Complications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Using Historical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Best Practices for Performing Your Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Avoiding a Common Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter 3
Assessment and Analysis 69
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Project Scope and Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Evaluating Upgrade Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Business Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Technical Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Gathering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Assessing Application Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Application Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
 Contents v

Application Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Using the Assessment Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Current and Target Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Inventory to Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Source Code Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Handling Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Application Dependences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Missing Application Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Estimating Effort and Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Aspects to Be Estimated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Understanding the Effort – Total Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Understanding the Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Chapter 4
Common Application Types 107
Identifying and Upgrading Application Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Determining Application Type and Functional Equivalency . . . . . . . . . . . . . . . . . . . 108
Determining Component and Project Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Desktop and Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Architecture Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Desktop Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Application Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Native DLLs and Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Interoperability Between .NET and COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Reusable Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
ActiveX Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
ActiveX Controls Embedded in Web Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
ActiveX Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Distributed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
DCOM Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
MTS and COM+ Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Chapter 5
The Visual Basic Upgrade Process 139
Procedure Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Application Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Development Environment Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Upgrade Wizard Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Removing Unused Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
vi Contents

Obtaining the Application Resource Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Compilation Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Project Upgrade Order Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Determine All Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Reviewing the Upgrade Wizard Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Application Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Execution of the Visual Basic Upgrade Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Verifying the Progress of the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Fixing Problems with the Upgrade Wizard Execution . . . . . . . . . . . . . . . . . . . . . . . 166
Completing the Upgrade with Manual Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Testing and Debugging the Upgraded Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Upgrade Report Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Fixing Run-Time Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 6
Understanding the Visual Basic Upgrade Wizard 183
Using the Upgrade Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Tasks Performed by the Upgrade Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Code Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Reference Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
The Upgrade Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Supported Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Visual Basic 6.0 Language Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Visual Basic 6.0 Native Libraries (VB, VBA, VBRUN) . . . . . . . . . . . . . . . . . . . . . . . 203
Visual Basic 6.0 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
ActiveX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Chapter 7
Upgrading Commonly-Used Visual Basic 6.0 Objects 217
Upgrading the App Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Upgrading the Screen Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Upgrading the Printer Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Upgrading the Printers Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Upgrading the Forms Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Upgrading the Clipboard Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Upgrading the Licenses Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Upgrading the Controls Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
 Contents vii

Chapter 8
Upgrading Commonly-Used Visual Basic 6.0 Language Features 247
Resolving Issues with Default Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Resolving Issues with Custom Collection Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Dealing with Changes to Commonly-Used Functions and Objects . . . . . . . . . . . . . . . . 253
Dealing with Changes to TypeOf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Upgrading References to Visual Basic 6.0 Enum Values . . . . . . . . . . . . . . . . . . . . . . 258
Defining Your Own Constant Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Using the Non-Constant Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Dealing with Changes to Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Legacy Visual Basic Language Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Upgrading Add-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Chapter 9
Upgrading Visual Basic 6.0 Forms Features 275
Handling Changes to Graphics Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Removal of the Line Control in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . 275
Removal of the Shape Control in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . 276
Handling Changes to the PopupMenu Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Handling Changes to the ClipControls Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Drag-and-Drop Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Drag-and-Drop Functionality in Visual Basic 6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Drag-and-Drop Functionality in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . 282
Handling Changes to the MousePointer and MouseIcon Properties . . . . . . . . . . . . . . 286
Handling Changes to Property Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Handling Changes to the OLE Container Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Handling Changes to Control Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Event Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Accessing Control Arrays as a Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Adding Controls Dynamically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Handling Changes to DDE Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Chapter 10
Upgrading Web Applications 301
Upgrading ActiveX Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Upgrading Web Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
viii Contents

Chapter 11
Upgrading String and File Operations 307
Operations Handled by the Upgrade Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Auto-Upgraded String Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Auto-Upgraded File Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Manual String and File Operation Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Replacing Strings with StringBuilders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Replacing Complex String Manipulation with Regular Expressions . . . . . . . . . . . . . 314
Improving File I/O with Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
File Access Through the File System Object Model . . . . . . . . . . . . . . . . . . . . . . . . 319
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Chapter 12
Upgrading Data Access 323
General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
ActiveX Data Objects (ADO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Upgrading ADO Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Projects without ADO Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Upgrading Data Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Upgrading Data Environment with Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Data Access Objects and Remote Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Data Binding Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
DAO/RDO in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Replacing the Data Control with ADO Data Control in Visual Basic 6.0 . . . . . . . . . . 332
Replacing DAO/RDO with ADO in Visual Basic 6.0 . . . . . . . . . . . . . . . . . . . . . . . . 334
Upgrading DAO / RDO without Data Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Upgrading Data Access Objects (DAO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Upgrading Remote Data Objects (RDO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Custom Data Access Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Upgrading to a .NET Version of the Component . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Using COM Interop with Custom Data Access Components . . . . . . . . . . . . . . . . . . 346
Upgrading Mixed Data Access Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Converting Data Reports to Crystal Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Chapter 13
Working with the Windows API 351
Type Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Changes to Integer and Long Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Changes to Fixed-Length Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
 Contents ix

Variable Type “As Any” Is No Longer Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Passing User-Defined Types to API Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Changes to “AddressOf” Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Functions ObjPtr, StrPtr, and VarPtr Are No Longer Supported . . . . . . . . . . . . . . . . . . 363
Moving API Calls to Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Chapter 14
Interop Between Visual Basic 6.0 and Visual Basic .NET 371
Calling .NET Assemblies from Visual Basic 6.0 Clients . . . . . . . . . . . . . . . . . . . . . . . 372
Calling Visual Basic 6.0 Libraries from Visual Basic .NET Clients . . . . . . . . . . . . . . . 372
How to Achieve Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Access Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Requirements for Interoperability with COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Accessing .NET Assemblies Directly from Visual Basic 6.0 . . . . . . . . . . . . . . . . . . 375
Creating Interoperability Wrappers in .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Command Line Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Data Type Marshaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Error Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Sinking COM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
OLE Automation Call Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Resource Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Constructors and Destructors in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . 395
Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Chapter 15
Upgrading MTS and COM+ Applications 399
Using MTS/COM+ in Visual Basic 6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Using COM+ in Visual Basic .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
COM+ Application Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Using SOAP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
COM+ Application Proxies in .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Upgrading MTS/COM+ Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
COM+ Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
COM+ Compensating Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
COM+ Object Pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
COM+ Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
COM+ Shared Property Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
COM+ Object Constructor Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
COM+ Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
x Contents

Additional COM+ Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

COM+ Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Context Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
COM+ Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
The Event Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
The Event Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
The Event Subscriber and Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Message Queuing and Queued Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

Chapter 16
Application Completion 455
Separating Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
No Assembly Separation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Separation by Application Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Separation by Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Upgrading Integrated Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Integrating Help at Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Integrating Help at Design Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Upgrading WinHelp to HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Integrating Context-Sensitive Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Run-time Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Upgrading Application Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Creating a New Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Customizing Your Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Merge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Web Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
COM+ Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Chapter 17
Introduction to Application Advancement 477
Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Advancing the Architecture, Design, and Implementation . . . . . . . . . . . . . . . . . . . . . . 478
Advancing Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Taking Advantage of Object-Oriented Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Layering Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
 Contents xi

Chapter 18
Advancements for Common Application Scenarios 497
Windows Applications and Windows Forms Smart Clients . . . . . . . . . . . . . . . . . . . . . 497
Business Components (Enterprise Services) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

Chapter 19
Advancements for Common Web Scenarios 527
Web Applications and ASP.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Architectural Advancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Master Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
HTTP Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Web Services Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Architecture Advancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Creating a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Consuming a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Technology Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

Chapter 20
Common Technology Scenarios 541
Application Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Using Identities and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Using Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Application Manageability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Using Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
Using Deployment and Update Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Using Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Using Tracing and Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Application Performance and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Exception Handling Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
String Handling Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Database Access Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
Multithreading and the BackgroundWorker Component . . . . . . . . . . . . . . . . . . . . . 554
Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Communication and State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Moving From DCOM to HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556
Replacing Message Queuing with System.Messaging . . . . . . . . . . . . . . . . . . . . . . 558
Upgrading ODBC and OLE DB Data Access Components . . . . . . . . . . . . . . . . . . . . . . 559
The ODBC .NET Data Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
xii Contents

The OLE DB .NET Data Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

Accessing Oracle Databases from the .NET Framework . . . . . . . . . . . . . . . . . . . . . 562
Upgrading ADO to ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
ADO.NET Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
ADO vs. ADO.NET Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Chapter 21
Testing Upgraded Applications 571
Fitch & Mather Stocks 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Test Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Testing Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Create Test Plan and Test Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Create Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Review the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Review of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Performing Unit Testing – White Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
White Box Testing – Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
An Overview of Test Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Test Strategy Based on the Waterfall Methodology . . . . . . . . . . . . . . . . . . . . . . . . 586
Test Strategy Based on the Iterative Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 589
Test Strategy Based on the Agile Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Tools for Testing Visual Basic .NET Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
NUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
FxCop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Application Center Test (ACT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Visual Studio Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Trace and Debug Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
TraceContext Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
CLR Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Enterprise Instrumentation Framework (EIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Performance Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

Appendix A
References to Related Topics 601
Visual Basic 6.0 Resource Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Coding Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Choosing File I/O Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
 Contents xiii

Appendix B
Application Blocks, Frameworks, and Other Development Aids 603
Using Visual Basic .NET Application Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Building “My” Facades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Building Visual Studio .NET Snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Mobile Applications and the .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . 607
Microsoft Mobile Technology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Overview of the .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Porting from eMbedded Visual Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Creating a Mobile Version of a Desktop Application . . . . . . . . . . . . . . . . . . . . . . . 614
Synchronizing with Server Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

Appendix C 623
Introduction to Upgrading ASP 623
Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Preparing the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Upgrading the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Testing and Debugging the Upgraded Application . . . . . . . . . . . . . . . . . . . . . . . . . 627
Understanding the ASP to ASP.NET Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . 627
Tasks Performed by the Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Limitations of the Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Preparing the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Preparing the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Preparing Your Code for the Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Upgrading the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Upgrade Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Using the ASP to ASP.NET Migration Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Completing the Upgrade with Manual Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Testing and Debugging the Upgraded Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

Appendix D
Upgrading FMStocks 2000 —
A Case Study 645
About FMStocks 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Reasons FMStocks 2000 Is Used for the Case Study . . . . . . . . . . . . . . . . . . . . . . 646
FMStocks 2000 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
FMStocks_AutomatedUpgrade Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
FMStocks_NET Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
xiv Contents

FMStocks 2000 Assessment and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

Overview of the Structure of FMStocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Overview of the Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Obtaining the Upgrade Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Obtaining Source Code Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Handling of Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Determining Application Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Upgrading FMStocks 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Planning the Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Preparing the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Executing Automated Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Applying Manual Upgrade Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Functional Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678

Index 679
Preface
Microsoft® Visual Basic® development system is one of the most popular program-
ming languages in use today. Its relative simplicity and power have helped shape
modern rapid application development, making it the language of choice for quickly
and efficiently building business applications.
Like any widely used product, Visual Basic continues to be improved and adapted
as the world of computer technology changes. Visual Basic .NET marks the next
evolution of the language.
Visual Basic has always been fairly easy to use and has provided techniques and
technologies that were current at the time of each version’s release. However, new
technologies and techniques have come into use since Visual Basic 6.0 was released,
and these are unavailable in this and earlier versions of the language. While object-
based programming has been available in the language for years, true object-oriented
features have been unavailable. The ability to build distributed applications has
been severely limited. Other technologies such as Web services, mobile devices, and
.NET have all become prominent in recent years. The need to support these and
other features has prompted the release of a new version of Visual Basic.
Visual Basic .NET marks a significant advance for the Visual Basic programming
language. As part of the Microsoft .NET Framework, it supports all the latest tech-
nologies for building powerful and extensible business applications. Object-oriented
programming techniques are now completely supported, making it possible to
implement full object-oriented designs. New forms features make it even easier to
build rich desktop applications. Moreover, Web forms make it equally easy to create
Web applications.
The changes made to Visual Basic .NET have made some features of earlier versions
obsolete. Although the new version does provide better ways to achieve the same
result as these obsolete features, the changes break compatibility with earlier ver-
sions of the language. This makes it impossible to automate the process of upgrad-
ing applications created in earlier versions of Visual Basic to the latest version.
Though it is possible to automate the process of upgrading applications created in
earlier versions of the language to the latest version, entire applications cannot be
upgraded through automation alone. Manual intervention will be required to
complete the upgrade process.
The purpose of this guide is to provide you with the information you need to up-
grade an application from Visual Basic 6.0 to Visual Basic .NET. It describes the tools
and techniques that you need to upgrade your application and to start taking
advantage of many new features in Visual Basic .NET and the .NET Framework.
xvi Preface

Who Should Read This Guide

This guide is intended for software technical decision makers, solution architects,
and software developers who are involved in Visual Basic 6.0 application or compo-
nent development. It helps you understand the issues and risks that go along with
upgrading to Visual Basic .NET. It also provides steps for preparing your applica-
tions for a successful and cost-effective upgrade. Finally, it gives ideas and pointers
about how to advance your application after you successfully upgrade it to Visual
Basic .NET.

For Technical Decision Makers

Technical decision makers will find a wealth of information about analyzing and
assessing the costs and benefits of upgrading Visual Basic 6.0 applications to Visual
Basic .NET and how best to perform this upgrade using proven processes and tools.
You will learn how to identify applications or parts of applications that may benefit
most from upgrading to .NET. You will also learn about the risks involved and the
issues that should be carefully monitored during the upgrade process. Finally, you
will learn about Visual Basic. NET improvements that you can apply to your appli-
cations after they are successfully upgraded.

For Solution Architects

Solution architects will learn how best to plan and execute the upgrade project. You
will learn how to effectively assess the complexity of the upgrade project and esti-
mate the effort that is required to complete the upgrade. You will find information
about how to identify the areas of your application that will need substantial
manual intervention to complete the upgrade. Furthermore, you will find a detailed
discussion about the best practices for completing a successful upgrade project and
how this maps to tasks and milestones within your own project.

For Developers
Developers will find information about many Visual Basic 6.0 features and how they
are upgraded to Visual Basic .NET. A step-by-step process describes the most effec-
tive strategies for completing a successful upgrade. A discussion of available tools
that automate some of the process is provided. You will also find information about
features that are not automatically converted and suggestions for how best to
manually convert these features. Code samples are provided throughout the text to
provide practical examples of Visual Basic 6.0 code that is not automatically up-
graded and examples of equivalent Visual Basic .NET code that you can use to
replace it. Finally, you will find ideas and pointers for improving your applications
after they are upgraded.
 Preface xvii

Prerequisites
As mentioned earlier, this guide is intended for software developers, solution
architects, and technical decision makers who are considering or who have already
decided to upgrade Visual Basic 6.0 applications to Visual Basic .NET. For this
reason, this guide assumes that you have a certain degree of knowledge and experi-
ence with Visual Basic 6.0. Also, you should be generally familiar with the .NET
Framework, Visual Basic .NET in particular.
This is not a how-to guide for Visual Basic 6.0, .NET application architecture, or
Visual Basic .NET. The guide contains introductory explanations of many of the
features of Visual Basic 6.0, Visual Basic .NET, and the .NET Framework in general,
but it provides these explanations only to create a context in which techniques for
upgrading between these technologies can be more appropriately discussed. If you
need more information about these technologies, see the “More Information” section
at the end of each chapter.

How to Use This Guide

Most chapters in this guide are independent and can be read in any order. However,
it is recommended that you read in order Chapter 1, “Introduction” and Chapter 2,
“Practices for Successful Upgrades.” These two chapters lay the important proce-
dural groundwork for the upgrade process that serves as a foundation for the rest of
the guide.
Because this guide targets a diverse audience, from architectural specialists who
oversee system design and integration to software developers who do the actual
coding, readers will undoubtedly get more value from some chapters than others.
The list that follows summarizes the key points of each chapter to help you deter-
mine which are more likely to focus on your particular areas of interest.
This guide has been divided into the following four parts:
● Part 1, “General Upgrade Practices,” consists of Chapters 1 – 3, and focuses on
the upgrade practices that are needed to make any upgrade project successful.
Although the emphasis is on Visual Basic 6.0 to Visual Basic .NET upgrades,
much of the information can be applied to any upgrade project. Part 1 includes
the following chapters:
● Chapter 1, “Introduction,” looks at the common reasons for upgrading to
Visual Basic .NET and examines some of the strategies that you might con-
sider to ensure a successful and cost effective upgrade.
● Chapter 2, “Practices for Successful Upgrades,” presents a proven methodol-
ogy that covers each step of the upgrade process from planning and applica-
tion preparation, through upgrading, and on to testing and quality assurance
in .NET.
xviii Preface

● Chapter 3, “Assessment and Analysis,” examines the first step of the upgrade
process which focuses on assessing the scope and complexity of the planned
upgrade project.
● Part 2, “Understanding the Upgrade Process,” consisting of Chapters 4 – 6,
provides a more technical overview of upgrading your code to Visual Basic .NET.
Part 2 includes the following chapters:
● Chapter 4, “Common Application Types,” examines the different types of
Visual Basic applications and presents suggestions for how to approach the
upgrade of these applications, shortcuts that can be taken, and some of the
difficulties and issues that can arise and should be kept in mind.
● Chapter 5, “The Visual Basic Upgrade Process,” looks more closely at the
preparations and steps of performing an upgrade. The chapter includes the
detailed steps involved in using the Visual Basic Upgrade Wizard, which is an
add-in to the Microsoft Visual Studio® .NET development system that per-
forms much of the upgrade work for you. This chapter shows you how to
prepare your application so that your use of the upgrade wizard is more
effective and the amount of code that is automatically upgraded is maximized.
● Chapter 6, “Understanding the Visual Basic Upgrade Wizard,” describes in
detail the capabilities and limitations of the Visual Basic Upgrade Wizard.
● Part 3, “Manual Upgrade Tasks,” consists of chapters 7 – 16, provides detailed
information on those aspects of upgrading that cannot be performed automati-
cally by the upgrade wizard and therefore require manual effort. Part 3 includes
the following chapters:
● Chapter 7, “Upgrading Commonly-Used Visual Basic 6.0 Objects,” catalogs
many of the objects used in typical Visual Basic 6.0 applications that are not
supported in Visual Basic .NET. It gives techniques for upgrading these objects
manually and suggestions for workarounds and alternatives to enable you to
complete the upgrade successfully.
● Chapter 8, “Upgrading Commonly-Used Visual Basic 6.0 Features,” identifies
additional Visual Basic 6.0 constructs that have changed or were omitted in
Visual Basic .NET. The chapter provides information on the changes that have
taken place and on how to deal with them when you upgrade an application.
● Chapter 9, “Upgrading Visual Basic 6.0 Forms Features,” concentrates on the
differences between Visual Basic 6.0 forms and the Windows Forms package
that is used in Visual Basic .NET. It identifies upgrade problem areas associ-
ated with forms and provides information on how to overcome them.
● Chapter 10, “Upgrading Web Applications,” provides information about how
to upgrade Web-based Visual Basic 6.0 applications.
● Chapter 11, “Upgrading String and File Operations,” gives information that
deals specifically with string and file manipulation. It covers the types of
 Preface xix

operations that are automatically upgraded when you apply the upgrade
wizard, as well as new operations that Visual Basic .NET offers.
● Chapter 12, “Upgrading Data Access,” addresses upgrading data access based
on Data Access Objects (DAO), Remote Data Objects (RDO), and ActiveX Data
Objects (ADO). It shows techniques that you can use to accelerate the upgrade
of database access code that is not handled by the upgrade wizard.
● Chapter 13, “Working with the Windows API,” discusses common issues that
arise when you upgrade Visual Basic 6.0 applications that use Windows API
function calls. It demonstrates how to replace common Windows API function
calls with new methods that Visual Basic .NET provides.
● Chapter 14, “Interop Between Visual Basic 6.0 and Visual Basic .NET,” presents
options for interoperability between these two versions of the language. It
addresses techniques to access Visual Basic 6.0 components from Visual Basic
.NET assemblies and to access .NET assemblies from clients built in Visual
Basic 6.0. It covers many issues that arise when you use Component Object
Model (COM) to interoperate between these two languages and how COM
works in unmanaged and managed environments.
● Chapter 15, “Upgrading MTS and COM+ Applications,” discusses how to
upgrade Microsoft Transaction Services (MTS) and COM+ components. It also
describes some of the deprecated functionality and how to deal with it when
you upgrade an application.
● Chapter 16, “Application Completion,” covers some of the remaining areas of
your application that are not core parts of your application’s functionality, but
are fundamental to having a finished product that provides the user with a
complete application. Topics include upgrading integrated help and product
deployment.
● Part 4, “Beyond the Upgrade,” consists of chapters 17 – 21 and covers what to do
after you complete the upgrade. Part 4 includes the following chapters:
● Chapter 17, “Introduction to Application Advancement,” looks at advance-
ment options that you can use after the application has reached functional
equivalence in Visual Basic .NET. The information in this chapter includes
suggestions for advancing the architecture, design, and implementation of
your applications.
● Chapter 18, “Advancements for Common Scenarios,” suggests advancements
that are based on specific application types, such as forms applications and
enterprise services.
● Chapter 19, “Advancements for Common Web Scenarios,” is a continuation of
Chapter 18 that focuses on advancements for Web-based applications.
xx Preface

● Chapter 20, “Common Technology Scenario Advancements,” focuses on

advancements that apply to almost all types of applications. These advance-
ments include enhancements to application security, manageability, perfor-
mance and scalability, and communication and state management.
● Chapter 21, “Testing Upgraded Applications,” provides detailed information
about strategies that you can use to verify the correctness and completeness of
your application after it is upgraded and after you have implemented the
advancements that you want.

Relevant Chapters for Technical Decision Makers

Technical decision makers will be most interested in information about assessment
and analysis, the risks and challenges of the upgrade, and application advancement.
The following chapters contain this information:
● Chapter 1, “Introduction”

● Chapter 3, “Assessment and Analysis”

● Chapter 7, “Upgrading Commonly-Used Visual Basic 6.0 Objects”

● Chapter 8, “Upgrading Commonly-Used Visual Basic 6.0 Language Features”

● Chapter 9, “Upgrading Visual Basic 6.0 Forms Features”

● Chapter 10, “Upgrading Web Applications”

● Chapter 11, “Upgrading String and File Operations”

● Chapter 12, “Upgrading Data Access”

● Chapter 17, “Introduction to Application Advancement”

● Chapter 18, “Advancements for Common Scenarios”

● Chapter 19, “Advancements for Common Web Scenarios”

● Chapter 20, “Common Technology Scenario Advancements”

Relevant Chapters for Solution Architects

Solution architects will be most interested in the information about the recom-
mended upgrade process, assessment and analysis, best practices for managing an
upgrade project, the risks associated with this process, and application advance-
ment. The following chapters contain this information:
● Chapter 2, “Practices for Successful Upgrades”

● Chapter 3, “Assessment and Analysis”

● Chapter 4, “Common Application Types”

● Chapter 7, “Upgrading Commonly-Used Visual Basic 6.0 Objects”

● Chapter 8, “Upgrading Commonly-Used Visual Basic 6.0 Language Features”

● Chapter 9, “Upgrading Visual Basic 6.0 Forms Features”

 Preface xxi

● Chapter 10, “Upgrading Web Applications”

● Chapter 11, “Upgrading String and File Operations”
● Chapter 12, “Upgrading Data Access”
● Chapter 13, “Working with the Windows API”
● Chapter 17, “Introduction to Application Advancement”
● Chapter 18, “Advancements for Common Scenarios”
● Chapter 19, “Advancements for Common Web Scenarios”
● Chapter 20, “Common Technology Scenario Advancements”

Relevant Chapters for Software Developers

Software developers will be most interested in the material that covers how the
technical features of Visual Basic 6.0 map to Visual Basic .NET. This includes the
features that are converted automatically by existing tools and those that must be
manually upgraded. Furthermore, developers are likely to be interested in learning
how they can advance applications with features of the .NET Framework. The
following chapters contain this information:
● Chapter 4, “Common Application Types”

● Chapter 5, “The Visual Basic Upgrade Process”

● Chapter 6, “Understanding the Visual Basic Upgrade Wizard”

● Chapter 7, “Upgrading Commonly-Used Visual Basic 6.0 Objects”

● Chapter 8, “Upgrading Commonly-Used Visual Basic 6.0 Language Features”

● Chapter 9, “Upgrading Visual Basic 6.0 Forms Features”

● Chapter 10, “Upgrading Web Applications”

● Chapter 11, “Upgrading String and File Operations”

● Chapter 12, “Upgrading Data Access”

● Chapter 13, “Working with the Windows API”

● Chapter 14, “Interop Between Visual Basic 6.0 and Visual Basic .NET”

● Chapter 17, “Introduction to Application Advancement”

● Chapter 18, “Advancements for Common Scenarios”

● Chapter 19, “Advancements for Common Web Scenarios”

● Chapter 20, “Common Technology Scenario Advancements”

Document Conventions
This guide uses the style conventions and terminology shown in Table 1 on the
next page.
xxii Preface

Table 1: Document Conventions

Element Meaning
bold font Characters that you type exactly as shown, including commands and
switches appear in bold font. Programming elements, such as methods,
functions, data types, and data structures appear in bold font (except
when part of a code sample, in which case they appear in monospace
font). User interface elements are also bold.
Italic font Variables for which you supply a specific value. For example,
Filename.ext could refer to any valid file name for the case in question.
New terminology also appears in italic on first use.
Monospace font Code samples.
%SystemRoot% The folder in which the Windows operating system is installed.

Feedback and Support

Every effort has been made to ensure the accuracy of the content of this guide. All
sample code and procedures have been independently tested. Also, all references
and descriptions of tools, specifications, and standards have been checked and are
believed to be accurate at the time this guide is published.
If you have any comments or suggestions, or if you find any inaccuracies, please
send them by e-mail to [email protected].

Note: There is a community site for this guide on GotDotNet. This site contains a “Downloads”
section where you can obtain the Visual Basic 6.0 Upgrade Assessment Tool that is described
in this guide. It also contains forums where you can post feedback, ask questions, or provide
suggestions.

Principal Authors
The content for this guide and the accompanying Visual Basic 6.0 Upgrade Assess-
ment Tool were developed by the following individuals at ArtinSoft:
● Project Lead: Federico Zoufaly

● Guidance: César Muñoz , Paul Dermody, Manfred Dahmen, Ronny Vargas,

Hendel Valverde, José David Araya, Oscar Calvo, Allan Cantillo, Alvaro Rivera,
Christian Saborío, Juan Fernando Peña, Xavier Morera, Iván Sanabria
● Assessment tool development: Rolando Méndez
 Preface xxiii

Contributors
The Visual Basic 6.0 Upgrade Assessment Tool and the Upgrading Visual Basic 6.0 to
Visual Basic .NET and Visual Basic 2005 guide were produced with the help of the
following people.
● Program Manager: William Loeffler (Microsoft Corporation)

● Product Manager: Eugenio Pace (Microsoft Corporation)

● Architect: Keith Pleas (Guided Design)

● Test: Edward Lafferty (Microsoft Corporation); Ashish Babbar, Terrence Cyril J.,
Manish Duggal, Chaitanya Bijwe, Arumugam Subramaniyam, Umashankar
Murugesan, Dhanaraj Subbian, Tarin R. Shah, Dipika Khanna, Gayatri Patil, and
Sandesh Pandurang Ambekar (Infosys Technologies Ltd)
● Documentation and Samples: RoAnn Corbisier (Microsoft Corporation); Tina
Burden McGrayne and Melissa Seymour (TinaTech Inc.); Sharon Smith (Linda
Werner & Associates Inc.); Francisco Fernandez and Paul Henry (Wadeware LLC)

Acknowledgements
Many thanks to the following individuals who provided invaluable assistance
during the development of this guide:
● Dan Appleman (Desaware Inc.)

● Joe Binder (Microsoft Corporation)

● Rob Copeland (Microsoft Corporation)

● Jackie Goldstein (Renaissance Computer Systems Ltd.)

● Ed Hickey (Microsoft Corporation)

● Billy Hollis

● Edward Jezierski (Microsoft Corporation)

● Chris Kinsman (Vergent Software)

● Deborah Kurata (InStep Technologies)

● Julia Lerman (The Data Farm)

● Rockford Lhotka (Magenic Technologies)

● Christian Nielsen (Volvo Information Technology AB)

● Jay Roxe (Microsoft Corporation)

● Jay Schmelzer (Microsoft Corporation)

● Scott Swigart (Swigart Consulting)

● The Visual Basic MVPs (Microsoft Valued Professionals)

xxiv Preface

More Information
For more information about the Visual Basic 6.0 Upgrade Assessment Tool and to
download it, see “Visual Basic 6 to Visual Basic .NET Migration Guide” on
GotDotNet:
http://www.gotdotnet.com/codegallery/codegallery.aspx?id=07c69750-9b49-4783-b0fc-
94710433a66d.
For more information about ArtinSoft, see the ArtinSoft Web site:
http://www.artinsoft.com.
1
Introduction
Before investing time, money, and energy into an upgrade project, it is important
to understand why an upgrade is beneficial. It is equally important to understand
potential upgrade strategies to minimize costs and risks. This chapter presents the
benefits of upgrading Visual Basic 6.0 applications to Visual Basic .NET, and pro-
vides several strategies that you can apply to successfully upgrade your application.

Why Consider an Upgrade Project?

Before deciding to upgrade an application from Visual Basic 6.0 to Visual Basic .NET,
it is helpful to understand why you should consider upgrading at all. This section
discusses why and when it makes sense to upgrade your application.
Usually, you have business requirements that compel you to upgrade an application
from Visual Basic 6.0 to Visual Basic .NET. Common reasons, or drivers, to upgrade
an application to Visual Basic .NET are:
● To Web-enable the application, or enhance an existing Web-enabled application
with ASP.NET features, such as tracing, flexible state management, scaleable data
access, and improved performance.
● To take advantage of the improvements in developer productivity and the en-
hanced development features that Visual Basic .NET, the .NET Framework, and
Visual Studio .NET provide — particularly if new functionality is required that
is more easily implemented in Visual Basic .NET, such as Web services.
● To consolidate your company’s software assets. For example, if your new applica-
tions are built in Visual Basic .NET, there is often a need to upgrade other applica-
tions built with earlier versions of Visual Basic. This improves system integration
and reduces the overhead of needing experts on different platforms.
2 Upgrading Visual Basic 6.0 Applications

● To reduce the cost of ongoing business activity. For example, the increased
scalability and performance of applications that are upgraded to Visual Basic
.NET, and the increased productivity of developers, can reduce the costs of
regular business activity.
● To improve the maintenance of an application in any of these situations:
● Your business does not have an in-house expert on the application.

● Your business has a high turnover of staff.

● Your business does not have enough resources to support the application.

● The available documentation is limited or outdated.

Of course, a combination of these drivers may influence your decision to upgrade.

These drivers can be seen as a kind of spectrum, going from push factors (factors that
compel you to upgrade the Visual Basic application to fit a new environment) to pull
factors (factors that result from the business wanting to seize an opportunity to
grow, reach new customers, or add products and services).

Minimum Information Needed to Make a Decision

To determine whether upgrading your application is appropriate, you should
perform a project feasibility analysis. The first step of your project feasibility analy-
sis is to collect information about the current status of your Visual Basic 6.0 applica-
tions. To make the best possible decision about whether to upgrade the application
to Visual Basic .NET, your analysis should address the following information.
● Project goals and priorities. Be sure to have clearly documented project goals,
with a list of priorities for each goal. Make a point to clarify how an upgrade will
meet these goals. Some questions that you want answered before making an
upgrade decision are the following:
● What is the expected life of the application? Is this a temporary solution or
something more long term? An application with a short expected lifetime
because of changing business needs or processes is unlikely to be worth
upgrading. However, an application whose functionality remains core to the
business and will remain so for a period that is sufficiently longer than the
length of the upgrade project is a good candidate for upgrading.
● When is the upgraded application needed for a production environment? If
the upgrade project will take longer than the schedule allows, it may be more
appropriate to replace the application.
● Do you have realistic expectations for improvements in performance, security,
scalability, and other potential benefits? Do you also understand that addi-
tional modifications may be required to achieve these improvements? It is
important to realize that the upgrade process alone may not improve the
performance or scalability of your application. Improvements like these often
 Chapter 1: Introduction 3

occur during application advancement, which is discussed in Chapter 20,

“Common Technology Scenario Advancements.”
● How many users will this application support in its lifetime? Do you clearly
understand how Visual Basic .NET will help meet increased user demand?
Changes to applications with a large user base will have a significant impact
on those users. However, the impact may be a positive one if the changes are
for the better. Improved performance features and modern technologies
available in Visual Basic .NET may improve the application experience for the
user.
● Do you plan to add new features to the application, such as integration with
other systems or access from the Web? Again, these improvements are part of
application advancement and require effort beyond upgrading the application.
● Business value of the applications. Is the functionality that is provided by this
application unique, or are there third-party applications that can be used to do
the same job? Be sure that you can demonstrate the specialized nature of the
application you propose to upgrade.
A related question is whether the application is a reasonable fit to your business
needs. You need to demonstrate that the application does provide a function that
fits the needs of your business. If the application has been around for a long time,
you need to make sure that the functionality of the application is not outdated,
and that it still closely fits the processes and operations required by your busi-
ness.
● Development environment. Moving to Visual Basic .NET also means updating
your development environment. Your developers will have to learn a new inte-
grated development environment (IDE), and a new language. You will also have
to purchase software licenses for the tools you need to perform the upgrade and
to maintain the upgraded code.
● Developer skills. Do your developers have knowledge or experience with the
.NET Framework in general and with Visual Basic .NET specifically? Although
upgrading an application is a good way to learn a new language, you should
ensure that your developers have basic knowledge of the .NET Framework and
Visual Basic .NET before beginning the upgrade project.
● Quality assurance environment. It is likely that the upgrade project will affect
your quality assurance procedures, especially if they are automated. Make sure
that you also consider any effort that will be required to upgrade your testing
environments.
● Application architecture and complexity. Most applications for large enterprises
have multiple dependencies on other systems within the company, as well as on
systems and libraries from third-party vendors. Make sure you understand the
nature of these dependencies and consider any changes that the systems require
before they will work with the upgraded application.
4 Upgrading Visual Basic 6.0 Applications

Also, consider the effects that an upgraded application will have on other appli-
cations that depend on it. How will they be affected by the move to Visual Basic
.NET?
Finally, is the application of good quality? Good quality indicates both its quality
as a business tool and the quality of the source code that implements it. This is an
assessment of the effective value of the application from the view of the user and
the developer. The user requires an application that is stable, that does the job
well, and that is easy to use. A developer requires an application with code that is
understandable, well-documented, and not unnecessarily complex.
Making the following three assessments will help you gather the information that
you need to make a decision about upgrading your application. They will also help
you accurately estimate the effort that is needed to select and complete the appropri-
ate upgrade process:
● Business value assessment

● Code quality assessment

● Development environment assessment

Business Value Assessment

When you are considering investing time and money into an upgrade project, it is
important to evaluate the importance of the existing application’s functionality to
your business. Is there opportunity for return on investment if you do upgrade the
application? This can be shown by determining how much has been invested in the
application so far. Also, you might highlight unique features of the application that
cannot be replaced by a third-party off-the-shelf product. Answering these questions
will help you determine the value of the application to your business:
● Are the application’s basic inputs and outputs based on legacy file formats?
Applications with inputs and outputs based on legacy file formats that are not
easily translatable may be problematic to upgrade. On the other hand, moving an
application to Visual Basic .NET and upgrading data to a more general format,
such as XML, may leverage your application for future enhancements or changes
in technology.
● What kind of data does the application process, and are there other applications
that can do the same job? Applications that are responsible for processing impor-
tant business data are highly valuable to your business. If there are no other
applications, such as third-party off-the-shelf products, available to process this
data, ensuring the lifespan of your application by upgrading it to Visual Basic
.NET may be a logical step.
● How does this application interact with its users, whether they are human or
computer-based clients? Providing a clean, friendly interface for human users
increases the value of an application. New or improved user interface features of
 Chapter 1: Introduction 5

a new language version, such as Visual Basic .NET, may increase user apprecia-
tion. Similarly, an application that coordinates with other applications must have
clean data transmission. It should use dependable data formats and communica-
tion protocols. Newer languages often support improved transmission protocols
or data formats that make inter-application communication simpler and more
reliable.
● What other systems depend on your application, and are there third-party prod-
ucts that could provide the same data or function? If other systems are dependent
on your application, and there are not any third-party products to replace your
application, the value of your application is high. Ensuring the future of the
application becomes more important in this situation.
● What business rules are inherent to your application that are difficult to repro-
duce elsewhere? An application with a large number of business rules that are
unavailable in other applications is very valuable to a company.
● What role does this application play in current business processes in your com-
pany? What would happen to those processes if the application was removed?
An application that automates a small number of mundane tasks is not likely to
be very valuable. In contrast, an application that processes large amounts of
business data will be highly valuable. Even applications designed to assist
employees by automating a large number of data-oriented tasks can be valuable,
if such an application improves user efficiency.
Another driver for upgrading an application is reducing the total cost of ownership
(TCO). The .NET Framework provides many features that increase developer pro-
ductivity, while also lowering deployment and maintenance costs to decrease TCO.

Code Quality Assessment

An important factor in determining whether to upgrade your application is the
current quality of its code design and implementation. Detailed analysis of your
application’s source code will provide information on code quality, design complex-
ity, and component dependencies. You can use the Visual Basic Upgrade Assessment
Tool to help capture some of this information. For a complete description of the tool,
see Chapter 3, “Assessment and Analysis.” The Visual Basic Upgrade Assessment
Tool is provided with this guide on the companion CD or you can download it from
the GotDotNet community site.
The assessment tool was created to help you estimate the effort that is required to
upgrade an application, but it can also help you understand the structural complex-
ity of the application and its design quality. For this discussion, design quality
indicates the suitability of the code implementation given the functionality that is
required by the application. For example, applications that have gone through
multiple iterations over several years with different programmers often contain
excessive redundant dependencies and unused code. This indicates poor design
quality.
6 Upgrading Visual Basic 6.0 Applications

The assessment tool collects the following metrics:

● Size metrics. These include metrics such as the number of lines of code, forms,
designers, modules, classes, components, user controls, and data sources.
● Usage metrics. These include functions, types, and properties.

● Complexity metrics. The assessment tool recognizes the same things that cause
the upgrade wizard to generate errors, warnings, and issues (EWIs). These EWIs
imply specific modifications that are required to resolve them. The assessment
tool assigns complexities to these EWIs. This helps you estimate the work that
needs to be performed to remedy all of the reported issues.
● Dependency diagrams. The assessment tool generates the call graphs for each
function and the resulting dependencies between modules and files. In addition,
the tool lists missing libraries and files. Use this information to determine pos-
sible upgrade roadmaps — that is, the order in which modules should be up-
graded.
There are many types of applications and different technologies that can be used to
build them. If you are considering upgrading your applications with the Visual Basic
Upgrade Wizard, you should be aware of some of the tool’s limitations. The follow-
ing types of applications are a sample of the those with features that are only par-
tially supported, or are not supported at all, by the upgrade wizard and some that
are not supported at all by Visual Basic .NET:
● A complex distributed application with several different layers of objects that
communicate through COM.
● A Visual Basic 5.0 or earlier application that has not made the transition to Visual
Basic 6.0.
● An Internet project that uses Microsoft ActiveX® technologies, Web classes, or
DHTML. None of these development technologies is supported in Visual Basic
.NET.
● A database project that is based on the Data Environment Designer, which is also
not supported in Visual Basic .NET.
● A database project that uses data binding to bind data sources to controls.

● An ActiveX control or ActiveX DLL project.

● A database client application with user controls.

Although these features and applications are not directly supported in Visual Basic
.NET, there is always an alternative (and often better) way to achieve the same
functionality within Visual Basic .NET. A more complete list of features that are not
automatically upgraded by the upgrade wizard is given in Chapters 7 through 11.
If your applications fit into any of these scenarios, your project plan should allow
time to identify and analyze upgrade alternatives for the technologies involved. You
should also allocate time to review, re-design, and realize your target architecture.
 Chapter 1: Introduction 7

Code quality is also affected by the status of the development work on the original
application. If any development initiatives are currently in progress, the code will be
less stable. The code may contain bugs, incomplete features, or even invalid code
that will not compile.
The best time to upgrade is when the application code base is stable but is due for
enhancements. This strategy gives you the opportunity to combine the upgrade
effort with feature enhancements. In contrast, it is best to avoid upgrading your
applications when undergoing a period of intense change, unless you have a very
strongly controlled code management process. Upgrading a large application may
take several weeks or even months. During this time, changes made to the original
code base will also be required in the upgraded code base. The process of maintain-
ing two code bases that are each undergoing changes is prone to error and is likely
to result in a disparity between the two versions of the application. If you decide
that it is necessary to make changes to the original applications while you also
upgrade them, it is recommended that you minimize disruption by choosing mod-
ules to upgrade that are stable and that progressively cover all of your application.
Code quality can affect the decision to upgrade in many ways. A stable application
with a well designed, implemented, tested, and documented code base that has
drifted away from the business needs (either through revisions in the application or
changes to the business) is a prime candidate for upgrade. On the other hand, such a
stable application that does fulfill the business needs and does not require improve-
ments is probably better left in its original form. An application of poor quality with
a weak design, complex implementation, and/or poor documentation is also a good
candidate for an upgrade. Upgrading an application of poor quality to a new devel-
opment language, such as Visual Basic .NET, gives you the opportunity to correct
these shortcomings. This will make it easier to maintain and will possibly advance
the application.

Development Environment Assessment

To accurately assess your development environment, you need to consider the skills
of your development team. The productivity of developers in an upgrade project
depends on their knowledge of the existing source code and the target technologies.
It is necessary to assess whether the team’s current skills are capable of solving each
issue that is found during the upgrade analysis. In general, it is recommended that
the developers undergo full training in Visual Basic .NET before they attempt an
upgrade project.
You must also consider other factors, such as the existence of test cases and how well
your development team understands the application that will be upgraded. If the
application does not have well defined test cases, it will be more difficult to demon-
strate the completion of an upgraded application. When test cases do exist, they may
8 Upgrading Visual Basic 6.0 Applications

also need to be upgraded to Visual Basic .NET. This is especially true if the testing
process is performed with automated tools.
If the developers do not have previous knowledge of the application, you must
factor extra time for them to understand the design and implementation of the
application. The time that is required also increases if the application does not have
an adequate set of documentation.

Upgrade, Reuse, Rewrite, or Replace?

When it is necessary to update an application, you have four broad options to
choose from: upgrade, reuse, rewrite, or replace. These options are described here:
● Upgrade. Apply the upgrade process, adding functionality and business reach as
required. The advantages of upgrading are that a great deal of your previous
investment is leveraged (especially in the areas of business logic). Also, compared
to rewriting your application, an upgrade is likely to introduce fewer bugs,
particularly when you use automated upgrade processes.
● Reuse. Instead of updating the application, you can add a layer over the applica-
tion to enable it to interoperate with newer Visual Basic .NET systems in your
organization. However, if you are updating your application for consolidation
reasons, reuse is not an option because with it you will have to maintain both
Visual Basic 6.0 and Visual Basic .NET systems.
● Rewrite. Sometimes the only way to update an application is to start over and
completely rewrite it. This means disposing of the original application and
starting again from scratch. If you determine that gradual changes in your busi-
ness operating procedures have caused the application to slowly lose relevance
and it no longer serves your business needs, you may consider rewriting most or
all of the application. Another reason for rewriting the application is that it has
become overly complex with un-maintainable, redundant code, and has out-of-
date documentation. This can happen when multiple versions of an application
were written by different developers who are no longer available to work on the
latest version.
The advantage to rewriting an application is that you have the freedom to create
a completely new design with the most current technologies. The disadvantage is
that writing a new application, even if it is a redevelopment of an existing appli-
cation, is more costly and more risky than the other options. Also, when you
rewrite a new application, you are effectively discarding all investment in the
existing application.
● Replace. Look for a suitable package to replace the application, or outsource the
work it does. Be prepared to make changes to your business model to meet the
package half-way because it is unlikely that it will exactly suit your current
needs.
 Chapter 1: Introduction 9

Use the following lists of indicators to help you choose an option for updating all or
part of your application:
● Indicators for choosing to upgrade. These include:

● The existing application is a good fit with business needs.

● The existing application needs only moderate functionality changes.

● A new application would require adding significant functionality to it, and it

would need to be closely integrated with the existing application.
● High operational costs are associated with the existing application.

● It is necessary to upgrade to .NET for strategic reasons.

● A future vision of the application includes Web services.

● It is difficult and costly to find resources to maintain the existing application.

● Indicators for choosing reuse. These include:

● The business rules are satisfactory.

● The existing application has low operational costs.

● It is difficult to separate logic from persistent data and presentation layers.

● Only simple Web access is required, which allows you to use a wrapping
solution
● You have sufficient resources to maintain core legacy code.

● Off-the-shelf software is central to the existing application, and it is possible to

rely on third-party support and maintenance.
● Indicators for choosing rewrite. These include:
● The business rules are satisfactory but you will need to add additional func-
tionality to the application.
● The available off-the-shelf solutions do not come close to meeting your needs.

● The existing application has poor quality code.

● The existing application has high maintenance costs.

● The time, cost, and disruption of rewriting the application are acceptable.

● Indicators for choosing replace. These include:

● The existing application is significantly out of line with business needs.

● Making changes to the business model to fit an off-the-shelf solution is accept-

able.
● The time, cost, and disruption of replacing the application are acceptable.

Figure 1.1 on the next page provides a visual summary of these indicators. To use
this graph, you need to first determine where your current application stands in
terms of business value and quality.
10 Upgrading Visual Basic 6.0 Applications

Custom

Rewrite Migrate
Business
Value
Replace Reuse

Standard
Low High

Application Quality
Figure 1.1
A visual guide for deciding when and how to upgrade an application

Business value is the vertical access on the left. If your application provides some
level of “standard” functionality that is easily found in other applications, particu-
larly third-party off-the-shelf products, it will be located lower down on this axis. If
your application is a custom built application whose functionality is unique to your
business needs, it will appear higher up on this axis.
The horizontal axis at the bottom represents the quality of an application from the
points of view of both the user and the developer. If your application is difficult to
use, slow, unstable, or gives inconsistent results, the user will see it as a low quality
application. If the code is complex and difficult to maintain, the developer will see it
as low quality. In both cases, the application will be located to the left of the applica-
tion quality axis. If both users and developers are happy with the application, it will
be located to the right of this axis.
After you determine where the application stands on both axes, you can determine
the best course of action for updating your application. In general, applications that
provide “standard” functionality are candidates for replacement or reuse while
applications that provide “custom” functionality are candidates for rewriting or
upgrading. Low quality applications should be replaced or rewritten while high
quality applications should be reused or upgraded.
When indicators are in favor of an upgrade, choosing to upgrade to Visual Basic
.NET will best leverage the existing code base. For more information about some of
these benefits, see the “Moving from Visual Basic 6.0 to Visual Basic .NET” section
later in this chapter.

Partial Upgrade
So far, this chapter has discussed the updating of your application as an all or
nothing undertaking. You can upgrade it or you can leave it as it is. You can rewrite
it or you can replace it. However, for many applications it is not a straightforward
question of choosing one of the four options previously listed. In some cases, you
 Chapter 1: Introduction 11

need to look at a combination of the upgrade, reuse, rewrite, and replacement

options. For example, a combination of upgrading and reusing the application is
possible and involves upgrading only part of your application. You can use standard
interoperability mechanisms to integrate the new and legacy components. This
approach is known as a partial upgrade and it makes sense when you determine
that certain parts of your application will benefit from the move to Visual Basic
.NET, but it is difficult to justify the move for others. In particular, if you examine
the indicators previously listed and find that the indicators for choosing to upgrade
apply to part of your application while the indicators for choosing to reuse apply to
other parts, you may want to consider a partial upgrade.
If you determine that a partial upgrade is the way to update your application, you
might find that you will have less upgrade work to do because you are not upgrad-
ing your entire application. However, you may have additional work to do to
integrate your new application with the legacy components that have been left in
Visual Basic 6.0. For more information about interoperability, see Chapter 14,
“Interop Between Visual Basic 6.0 and Visual Basic .NET.”

Upgrade Strategies
If you decide that the upgrade option is the right approach to update your applica-
tion, you also need to choose an appropriate upgrade strategy. For information
about possible strategies, see the “Selecting an Upgrade Strategy” section in Chapter
2, “Practices for Successful Upgrades.”

Moving from Visual Basic 6.0 to Visual Basic .NET

It is important to understand when to upgrade to Visual Basic .NET, and it is just as
important to understand why you should upgrade. It is important to understand the
benefits of upgrading before you begin. All of the features in Visual Basic 6.0 do not
have a one-to-one mapping with features in Visual Basic .NET, and you cannot
automatically upgrade all of the code. A natural question then arises: What reasons
are there for upgrading functional Visual Basic 6.0 applications to Visual Basic .NET?
To fully understand the advantages of upgrading, it is necessary to first understand
the benefits of Visual Basic .NET, the .NET Framework, and the standard .NET
integrated development environment, Visual Studio .NET.

Increased Productivity
The Visual Basic .NET language contains many new language features that increase
developer productivity. This section explores some of these features, and explains
how they benefit application development.
12 Upgrading Visual Basic 6.0 Applications

Visual Basic .NET is built around the .NET Framework. Many of the benefits
of Visual Basic .NET are derived directly from the .NET Framework itself.
Microsoft .NET Framework is based on a specification named the Common Lan-
guage Specification (CLS). This specification defines the rules that determine a
minimum set of features that all .NET languages, including Visual Basic, must have.
Included among this minimum set of features are certain object-oriented features,
such as inheritance and exception handling. These features are not available in
earlier versions of Visual Basic. It also specifies which format the compilers create
for the executables, and it ensures that your application will run on any .NET engine
on any platform without recompilation.
The result is that code is compiled to a special format named Microsoft Intermediate
Language (MSIL) instead of the usual platform-specific machine code. MSIL
executables are then compiled to a platform-specific machine code at run time
through just-in-time (JIT) compilation. The benefit of this approach is that a single
compilation of your application is optimized at run time based on the actual proces-
sor and/or operating system on which the code is currently executing. For example,
a .NET application is optimized and run as a 32-bit application on the standard 32-
bit edition of the Microsoft Windows® XP operating system. The same application is
optimized and run as a 64-bit application, without the need for recompilation, on the
64-bit edition of the Microsoft Windows Server™ 2003 operating system. Because
this is a published specification, it is possible that new processors and operating
systems can have .NET run-time engines created for them as they are released. This
means that an application written for the .NET Framework can run on and be
optimized for new hardware or operating systems without any recompilation or
upgrading of the application. A multi-platform version of an application or compo-
nent means developers can solve new problems, instead of investing time porting
existing components.
Additionally, the MSIL contains metadata about the classes that it contains. The
result is that developers do not have to create “include files,” type libraries, Interface
Definition Language (IDL) code, or any other additional files to use these classes in
another application. The client application can automatically extract this information
from the MSIL. This makes sharing and using the MSIL a lot easier. Productivity
increases because it is easier to take advantage of existing classes.
The main component of the CLS implementation is named the common language
runtime (CLR), which is the engine on which all .NET applications run and which
enables the interoperability and integration between all .NET languages. The man-
agement of resources (such as memory, threads, exceptions, and security) for .NET
applications is handled automatically by the CLR. Applications that are built using
only .NET technologies are referred to as managed applications or managed code.
The term managed derives from the fact that resources in such applications are
 Chapter 1: Introduction 13

managed by the CLR. Developers who build managed code benefit from the delega-
tion of responsibilities to the CLR because it frees them to focus on the application
logic instead of low level logic of resource management. This allows software
developers to be far more productive because they can concentrate on solving
business problems.
The data typing rules are defined by a section of the CLS named the common type
system (CTS). This specification defines all of the .NET data types and their behav-
iors. As a result, all languages in .NET share a common set of base data types whose
storage requirements and functional behaviors are identical across all languages. For
example, a string is the same regardless of whether it is defined in a Visual Basic
.NET module, a managed Visual C++® library, a Visual C#® component, or a Visual
J#® package. The benefit is that the specification ensures that a parameter that is
passed from a Visual Basic .NET application to a Visual C# library will be inter-
preted correctly within the library, and the return value will behave as expected back
in the Visual Basic .NET application. The fact that the application and the library it
uses are written in two different languages is transparent to the developers of each.
This benefit results in increased productivity because Visual Basic .NET developers
can now more easily integrate existing libraries and components into their Visual
Basic .NET code, even when those libraries are developed in other languages.
An additional benefit of the CTS is that it enables any class written in a .NET lan-
guage to inherit behavior from a class written in any other .NET language. For
example, you can create a Visual Basic .NET class that inherits behavior from an-
other class that was developed in Visual C#. Moreover, you can extend the .NET
Framework itself from Visual Basic .NET. This significantly expands the set of
components that you can use and the ways in which you can use them. The increase
in productivity results from code reuse, even among different languages.
Applications built for the .NET Framework have access to a comprehensive class
library named the .NET Framework Class Library (FCL). It contains a large number
of classes that enable all categories of client and server application development.
The FCL contains classes for programming security, cryptography, Windows Forms,
Windows services, Web services, Web applications, I/O, serviced components, data
access to SQL Server™ and many other database systems, directory services, graph-
ics, printing, internationalization, message queues, mail, common Internet technolo-
gies and protocols, culture-specific resources, COM interoperability, .NET remoting,
serialization, threading, and transactions. The benefit of the FCL is that Visual Basic
.NET developers can use and expand existing components built on the FCL without
having to start from the beginning.
In Visual Basic .NET, the CLR is responsible for memory management. In particular,
the CLR manages the work of freeing up memory for objects that are no longer
referenced in an application. This process, garbage collection, happens automatically
any time the CLR runs low on memory. The benefit of this process is that developers
do not have to destroy unnecessary objects to free memory resources. This results in
14 Upgrading Visual Basic 6.0 Applications

increased productivity because a developer can invest more time in solving business
problems than in resource management issues.
Although Visual Basic 6.0 provided an object-based programming model, it lacks
some features that would make it a full object-oriented language. In particular,
Visual Basic 6.0 does not provide full inheritance. Although it supports interface
inheritance, this limited form prevents developers from taking advantage of the all
of the benefits of this object-oriented programming. For example, this type of inher-
itance does not allow for code reuse and it limits the ability to fully implement
object-oriented designs.
Visual Basic .NET supports full implementation inheritance. You can create new
classes that inherit from existing classes. In fact, you can perform implementation
inheritance regardless of the .NET programming language that was used to create
the super class. This means that you can now more fully reuse existing classes
through inheritance and can truly implement object-oriented designs.
In addition to implementation inheritance, Visual Basic .NET still supports interface
inheritance. An interface is defined with the Interface keyword. Your classes then
inherit from an interface by implementing its methods.
Furthermore, you can create forms that inherit from existing forms. This type of
inheritance is named visual inheritance, and it allows you to apply the layout,
controls, and code for existing forms to new forms. Through this form of inherit-
ance, developers can build standard base forms. These forms can then be inherited
by applications to give them a similar look and style, but it still gives the application
developers the freedom to expand the form by adding new controls or changing a
particular control’s behavior. The result of visual inheritance is that developers can
take existing forms and customize them for new applications, instead of having to
recreate new forms for each application.
The benefit of inheritance is that it enables code reuse. Developers can take existing
classes and forms, and through inheritance, customize them to meet an application’s
needs. The result is increased productivity because less time is invested in building
completely new components.
Visual Basic .NET includes support for a new form development system named
Windows Forms. The Windows Forms framework provides features that make the
creation of powerful forms-based applications easy. These features include all
standard Windows application form controls (such as buttons and text boxes), built-
in support for connecting forms to XML services, and ActiveX controls support.
These are only a few of the many features available in Windows Forms. The benefit
of this framework is that it allows developers to rapidly build forms applications.
 Chapter 1: Introduction 15

Control anchoring frees developers from writing code to deal with form resizing.
Now, controls on a form can be visually anchored so that they remain a fixed length
from the edge of the form and resize whenever the form resizes, with no effort on
the part of the developer. This frees the developer to focus on business logic, instead
of form manipulation, which makes the developer more productive.
For Web applications, Visual Basic .NET includes built-in support for Web Forms
and XML. These features increase productivity by simplifying the work that is
required to include them in your applications. You can even extend a functional
application into a Web service. Moreover, the Visual Studio .NET IDE includes
design tools that help to quickly and efficiently design HTML documents, as well as
XML documents and schemas. All these features provide you with an environment
in which the effort to build a Web application development is comparable to devel-
oping a Windows-based application.
In addition to the beneficial features in the Visual Basic .NET language itself, there
are productivity benefits to using the standard .NET IDE, Visual Studio .NET. Some
of these features are highlighted here.
The Windows Forms Designer gives developers all the tools they need to rapidly
design forms. Controls such as buttons, check boxes, and more can be added to a
form by dragging them to the form.
Visual Studio .NET also provides a WYSIWYG (what you see is what you get)
designer for Web pages. This enables developers to quickly design Web-based
solutions. Also, as previously mentioned, XML designers provide tools for rapidly
building XML enabled solutions.
Visual Studio .NET provides a Task List display, which shows the outstanding tasks
the developers need to complete. The Task List indicates any ToDo comments that
developers include in code as a way to remind themselves of these outstanding
tasks. The Task List provides a centralized view of these reminders, and allows
developers to jump immediately to the comment when the time to address the task
arrives.
The Task List also displays any compilation errors that need to be corrected. The
Visual Basic .NET compiler continuously works in the background during coding.
Compilation errors are flagged in real time with blue squiggle underlines in the
code. The Task List also updates in real time the list of compilation errors to give
developers a complete list of corrections that they need to make.
The Task List can also be filtered to show only particular types of outstanding tasks,
such as showing only compilation errors or only ToDo comments. Figure 1.2 on the
next page shows a typical Task List in a Visual Basic .NET solution.
16 Upgrading Visual Basic 6.0 Applications

Figure 1.2
ToDo comments in the Task List

The background compilation and Task List features enable developers to be more
productive by reminding them of unfinished tasks.
As mentioned earlier, the .NET Framework is designed for cross-language
interoperability. Controls and components written in one language can easily be
used in another language because the CLR unifies all data types. Anyone who has
struggled to get a Visual Basic 6.0 user control to work in a Visual C++ project can
recognize the benefits of this interoperability. Not only can you easily use a compo-
nent written in another .NET language, you can also inherit from a class written in
any other .NET language. You can also create components in other languages that
inherit from your Visual Basic .NET classes. Surprisingly, this interoperability does
not complicate development. Visual Studio .NET provides a single environment
for developing and compiling multi-language applications. A Visual Studio .NET
solution can contain several projects, where each project can be developed using a
different .NET language. Using the unified debugger, you can step through the
various components, even if they were written in different languages. You can also
debug COM+ services and step into SQL Server stored procedures.
A new feature of Visual Studio .NET is the Processes dialog box that allows you
to attach to and debug an already running process. Certain types of applications
require specialized execution environments that Visual Studio is unable to provide.
For example, a Windows service execution is handled by the Windows Services
Manager. Such applications do not have graphical user interfaces. Although it is
possible in some cases to provide a Windows service with a Main method and an
 Chapter 1: Introduction 17

appropriate test framework to enable debugging, it is often impossible to reproduce

a problem through any means except running the service in its natural environment
as a Windows service. Another situation in which the Processes dialog box is useful
is when you are executing an application outside Visual Studio .NET and the appli-
cation starts to behave in some unexpected way that is difficult to reproduce. The
Visual Studio .NET debugger provides a Processes option that allows the debugger
to attach to a currently executing process. This feature provides a means to debug
applications that are running outside of the IDE; this gives developers the flexibility
to handle these kinds of situations.
Visual Studio .NET provides a very high level of integration with SQL Server. You
can connect to SQL Server using Server Explorer. After you are connected, you can
browse the database and even create new objects. In particular, you can create and
edit stored procedures written in the native SQL Server procedure language TSQL.
After they are created, you can execute stored procedures from within Visual Studio
.NET. You can step into the stored procedures just as you can step into Visual Basic
.NET methods to debug them. You can set breakpoints so that SQL Server returns
control to Visual Studio .NET when a certain line of code is reached during the
execution of a stored procedure, function, trigger, or extended stored procedure.
Visual Studio .NET provides the ability to add references to other projects to your
solutions. When you do this, Visual Studio automatically calculates the dependen-
cies and the build order for your project and referenced projects. It also ensures that
all of the referenced assemblies are always up to date and that they are available in
the appropriate directories when they are needed.
The Immediate windows from earlier versions of Visual Studio have been enhanced
and are now named Command windows. You can use these windows to read values
from and write values to variables in a paused application, evaluate expressions,
and execute statements. You can also use them to execute any of the Visual Studio
commands that are available from menus, keyboard shortcuts, or toolbars. For
example, you can issue commands to add new or existing items to the project or
solution, perform search and replace operations using regular expressions, toggle
break points, add watches, examine the call stack and memory, and display the
current list of threads in a program. The Command window supports IntelliSense,
even for file names, which makes using the Command window much more efficient.

Better Integration
Visual Basic .NET is designed to easily interact with components built on the .NET
Framework and with legacy components. This section explores how improved
integration can benefit applications.
Assemblies are the fundamental unit of deployment in .NET. An assembly is a
collection of types and resources that form a logical unit of functionality, such as a
component or application, in the form of a dynamic link library (DLL) or executable
18 Upgrading Visual Basic 6.0 Applications

(EXE). An assembly also maintains information used by the CLR, such as the version
number of the assembly, the names of other assemblies it is dependent on, and
requests for security permissions.
An important part of being able to maintain and control dependencies between
components of an application is the ability to publish public interfaces that define
how the components can be used. This is important because it allows the developer
of a component to modify it, to improve it, or fix problems, without breaking code
written by clients of the component. Assembly isolation allows the component
developer to ensure that only a predefined subset of the component can be used
directly by clients. This allows the developer to make changes to the implementation
of the component without causing problems for or requiring changes to the clients,
as long as the public interface does not change.
Another benefit of assembly isolation is that it allows side-by-side execution. Side-
by-side execution refers to the ability to install multiple versions of an application,
third-party components used by an application, or the .NET Framework itself and to
have clients choose which version of the framework and/or components it uses at
run time. This results in better integration because developers no longer need to
worry about corrupting existing applications with the release of newer versions of
a module, component, or framework. Assemblies cannot corrupt each other, and
clients always know the correct version of an assembly to refer to.
Visual Basic .NET includes features that allow interoperability with COM compo-
nents. COM interop allows developers to create a bridge between managed Visual
Basic .NET code and the unmanaged code of a COM component for all basic data
types, such as numeric types and strings. Data types of parameters passed to and
return values received from COM components are converted to the proper equiva-
lents between the managed and unmanaged code. This mechanism, referred to as
data marshaling, ensures clean interoperability between the managed code of your
upgraded application and the unmanaged code of the COM component. Note that
in some instances, custom code for performing marshaling may be required for user-
defined types.

Application Extendibility
Extending an application with new technologies helps to leverage the investment in
that application. Visual Basic .NET includes many features that ease the process of
extending an application with additional technologies.
Visual Basic .NET supports multiple distributed technologies. One such technology
is Web services, an open standard that enables developers to expose a set of software
services over the Internet through XML. The .NET Framework provides built-in
support for creating and exposing Web services. Software services exposed in this
way are both scalable and extensible and embrace open Internet standards — HTTP,
XML, SOAP, and Web Services Description Language (WSDL) — so that a service
 Chapter 1: Introduction 19

can be accessed and consumed from any client or Internet-enabled device. Support
for Web services is also provided by ASP.NET.
Another example is a new technology unique to the .NET Framework named .NET
remoting. Remoting is similar to DCOM. It enables communication between applica-
tions. This communication can occur between applications on the same computer,
between applications on different computers on the same network, and even be-
tween applications on different computers across different networks. Support for
.NET remoting is available in Visual Basic .NET.

Improved Reliability
Some of the new features in Visual Basic .NET improve the reliability of components
and applications. This section describes some of these features and how they result
in improved reliability.
In Visual Basic .NET, data types are bound statically. This means that the type of a
variable must be known at compile time. Using this strategy, the compiler can verify
that only valid operations can be applied to a particular variable or value. The strict
data typing rules that are enforced by Visual Basic .NET and the CTS are not just to
provide a high level of compatibility between different languages. These rules also
create a development platform where errors caused by incorrect use of data are
identified as early as possible in the development life cycle, typically at compile
time. The increased interoperability of data types across components and strict
enforcement of data typing rules in Visual Basic .NET result in more reliable applica-
tions and components.
Visual Basic .NET helps you reduce programming errors by supporting stronger
type checking. For example, using the wrong enum value for a property or assign-
ing an incompatible value to a variable is detected and reported by the compiler.
Also, with ADO.NET, you can add typed datasets to your application. If code refers
to an invalid field name, it is detected as a compile error instead of a run-time error.
The earlier an error is found during the development cycle, the easier it is to correct.
Identifying type errors at compilation time instead of at execution time makes them
easier to correct.
It is possible to force even stronger type checking at compile time by using Option
Strict On in your application code. This option completely prohibits late binding
and requires you to use conversion functions whenever you assign to a variable a
value that is of a different type. This helps developers identify points in their code in
which subtle errors due to conversion may occur, such as the loss of a value due to
truncation when assigning a higher-precision value to a lower-precision variable (for
example, assigning a Long value to an Integer variable).
Another new feature of Visual Basic .NET that results in improved reliability is a
security feature that enforces the adherence to object-oriented concepts such as the
20 Upgrading Visual Basic 6.0 Applications

encapsulation of data and behavior. This feature, named type safety, protects memory
locations by restricting access to private members of an object. It ensures that when a
field or method is marked as private, it may be accessed only within the class to
which it belongs.
The term type safety also has a broader meaning that refers to language features that
reduce the number of run-time errors that relate to incorrect data types. In this
context, type safety refers to the compile-time checks that ensure operations are
performed on appropriate data type values.
In contrast, the type safety that is used to ensure .NET security is checked by the
compiler and can optionally be verified at run time using verification. Verification is
required because the runtime has no control over how various assemblies in the
application were compiled, but they may be skipped if the code in question has
permission to bypass verification. This kind of type safety guarantees that a class’s
public interfaces are respected, and that assemblies can be isolated from other
assemblies in the application domain. This improves reliability and security because
no other code can adversely affect execution by altering data or invoking functional-
ity that has been marked private. For more information about type safety and
verification in .NET, see “Type Safety and Security” in the .NET Framework
Developer’s Guide on MSDN.
Structured exception handling is another new feature of Visual Basic .NET that can
improve application reliability. In addition to supporting the familiar On Error
GoTo error catching mechanism from Visual Basic 6.0, Visual Basic .NET provides a
new structured error handling mechanism: the Try/Catch/Finally block and the
Throw statement.
A Try/Catch/Finally construct encloses code that may result in errors or other
exceptional conditions, and it provides handlers for each potential exception. A
software developer has full control over the granularity of the exception handling,
from an individual line of code, to an entire block of code, to all the code in a func-
tion. The developer also has control over the types of exceptions that are handled,
from specific exceptions to general catch-all exceptions. The optional Finally portion
of the construct provides a way to specify code that should execute regardless of
whether or not an exception occurred.
The Throw statement is a way for a developer to signal the occurrence of an errone-
ous or exceptional condition. This allows the developer to signal to a client that an
unexpected condition has occurred, and it gives the client the opportunity to decide
how to deal with the condition. A client may be able to recover from the condition or
provide a strategy to allow an application to gracefully degrade.
Structured exception handling gives developers a way to either recover from or
gracefully exit on error conditions. These strategies can help to prevent data loss;
this improves an application’s reliability even in the event of error.
 Chapter 1: Introduction 21

Improved Security
Application security is an important feature of Visual Basic .NET. The .NET Frame-
work provides a set of sophisticated security features without overcomplicating
requirements for developers. Security management in the CLR prevents others from
modifying the assemblies that contain an application or its dependent components.
It also ensures that components cannot access memory that they are not authorized
to access.
Developers can control the permissions of applications and components that use
configuration files. A developer can control access to a resource based on the privi-
lege level of the user running an application or based on the trust level of the appli-
cation itself. This can restrict untrusted code from accessing a resource even if the
user of the code would ordinarily have full access. For example, even if untrusted
code runs within a super-user account, its access to a resource can still be restricted.

Improved Deployment Options

Before .NET, deploying client applications typically required applying registry
settings and/or copying DLLs to appropriate directories. An application could
easily break if the registry settings were corrupted or if another application replaced
a DLL with an incompatible version.
Visual Basic .NET has many new features that have been designed to simplify rich
client application deployment. These features include the following:
● The .NET Framework provides application isolation. DLLs for one application do
not affect other applications. This is referred to as zero-impact installation.
● Components and DLLs by default are installed privately for the application.
These components must be shared explicitly to make them visible to other
applications.
● Multiple versions of a DLL can be shared transparently. An application’s assem-
bly contains all the required version information for any DLLs used. As a result,
even if multiple versions of the DLL exist on the target computer, only the correct
version will be used by the application.
● Self-contained applications and components can be deployed without registry
entries or dependencies. All that is required is copying the appropriate files to
the application’s bin directory. This type of installation is referred to as XCOPY
installation.
● Applications can take advantage of features available in the Microsoft Windows
Installer, such as advertisement, publishing, repair, and install-on-demand.
● Incremental installs provide for smaller downloads. Furthermore, if installation
fails, the target computer is fully restored to the stage it was in before the installer
began.
22 Upgrading Visual Basic 6.0 Applications

● A new type of installer called a merge module provides a much simplified way to
package and install components that will be shared by multiple applications.
Merge modules (.msm files) allow you to share components between multiple
deployment projects. You can create your own merge modules with Visual Studio
.NET, or you can use existing merge modules that are available for many stan-
dard components from Microsoft, as well as from third-party vendors. A merge
module is created once and is included in all applications that use it. It handles
all the details of remembering which applications are using the component and
when the last application that needs it has been uninstalled. For more informa-
tion about merge modules and other installation and deployment options, see
Chapter 16, “Application Completion.”
One of the results of improved deployment features in Visual Basic .NET is that
installations can no longer corrupt other application installations.

Increased Performance
Some new features of Visual Basic .NET can be used to increase the performance of
an application. This section explores some of these features and how they can be
used to increase performance.
A typical Visual Basic application is single threaded, which means that only a single
task at a time can be performed. However, Visual Basic .NET now provides support
for multithreaded applications, so that multiple tasks can execute concurrently.
Multithreading can improve application performance in the following ways:
● Program responsiveness increases because the user interface can remain active
while other work continues.
● Idle tasks can yield their designated processor time to other tasks.

● Processor-intensive tasks can periodically yield to other tasks.

As an example, consider a server application that provides information to clients

from a database. In a single-threaded application, the server is capable of servicing a
single client at a time. This means that if multiple clients need information at the
same time, only one is serviced. The other clients have to wait until the first client’s
request is complete before they receive attention. In a multithreaded application, the
server has multiple independent threads of execution servicing individual client
requests simultaneously. As a result, each client receives immediate attention from
the server.

Technical Support
As of March 2005, Microsoft ended the mainstream phase of support for Visual Basic
6.0, and entered into a period of extended phase support. The current extended
phase support is available until March 2008, at which point Visual Basic 6.0 will no
longer be supported.
 Chapter 1: Introduction 23

The impact of these support policies is that free support for Visual Basic 6.0 is no
longer available. During the extended phase, customers can still receive professional
product support for Visual Basic 6.0 through telephone and online incident support
channels on a per-incident fee basis or through Premier Support. Similarly, critical
updates and hotfixes are only available for a fee during the extended phase.
For more information about the support policies for Visual Basic 6.0, see “Product
Family Life-Cycle Guidelines for Visual Basic 6.0” in the Microsoft Visual Basic
Developer Center on MSDN.

Benefits of the Visual Basic 6.0 to Visual Basic .NET Upgrade Wizard
If you choose to upgrade your application, you can best achieve this by using the
Visual Basic 6.0 to Visual Basic .NET Upgrade Wizard included in the Visual Studio
.NET IDE. By using the upgrade wizard to upgrade your application, you can:
● Produce source code that is both easily extendable and maintainable.

● Acquire functional equivalence, with all of the built-in features of the original
program intact.
● Gain a robust and intelligent automatic restructuring of the code.

● Keep original code comments.

● Maintain cross-references for all the application components.

Some of these benefits may be reduced or lost if an application uses many technolo-
gies that are not supported in Visual Basic .NET. The Visual Basic 6.0 Upgrade
Assessment Tool can help to identify an application’s dependence on such technolo-
gies, and this guide provides the solutions for addressing dependence on unsup-
ported technologies in Visual Basic .NET.

Summary
When you decide whether to upgrade Visual Basic 6.0 applications to Visual Basic
.NET, you have many factors to consider. Some applications are not well suited to an
upgrade, either because they will not benefit from .NET technologies or because the
cost or complexity of the upgrade is prohibitive. Other applications practically
compel the move because the benefits far outweigh the costs. The main point of this
chapter is that an upgrade should be considered on a per-application basis. There
are many convincing reasons for upgrading applications to Visual Basic .NET, but
there are often just as convincing reasons to leave an application alone. Upgrade an
application only if and when it makes sense to do so. If an upgrade is warranted,
risks and costs can be minimized by preparing an upgrade plan. The remaining
chapters of this guide provide you with the tools and techniques to prepare such a
plan, and to help you perform the actual upgrade as efficiently as possible.
24 Upgrading Visual Basic 6.0 Applications

For More Information

For more information about the Visual Basic Upgrade Assessment Tool or to down-
load it, see “Visual Basic 6 to Visual Basic. NET Migration Guide” on the GotDotNet
community site:
http://www.gotdotnet.com/codegallery/codegallery.aspx?id=07c69750-9b49-4783-b0fc-
94710433a66d.
For more information about type safety and verification in .NET, see “Type Safety
and Security” in the .NET Framework Developer’s Guide on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html
/cpcontypesafetysecurity.asp.
For more information about the support policies for Visual Basic 6.0, see “Product
Family Life-Cycle Guidelines for Visual Basic 6.0” in the Microsoft Visual Basic
Developer Center on MSDN:
http://msdn.microsoft.com/vbasic/support/vb6.aspx.
2
Practices for Successful Upgrades
This chapter examines the upgrade process in detail, and further discusses two key
concepts that were introduced in Chapter 1: functional equivalence and application
advancement. This chapter also presents upgrade practices that apply to these two
concepts and explains some best practices for managing a successful upgrade
project.

Functional Equivalence and Application Advancement

When you upgrade an application from Visual Basic 6.0 to Visual Basic .NET, you
can either choose to stop the upgrade process when you have a Visual Basic .NET
version of an application that looks and behaves the same as the original, or you can
choose to add new features that are available in the new language. This section
explains these two options, functional equivalence and application advancement.

Functional Equivalence
Functional equivalence is an important concept for any upgrade project. In the
context of a Microsoft Visual Basic upgrade, achieving functional equivalence means
that the exact functionality of a Visual Basic 6.0 application is retained in the Visual
Basic .NET application after it has been upgraded, but before new features are
added. Achieving functional equivalence guarantees that your application logic does
not change as a result of the upgrade and that your existing business rules are
functional in the upgraded application.
By making functional equivalence a goal for your upgrade project, your organiza-
tion can benefit in several ways:
● Because your Visual Basic .NET application is functionally equivalent to the
original Visual Basic 6.0 application, you have a perfect specification for the
application upgrade project. This means that you can easily identify discrepan-
26 Upgrading Visual Basic 6.0 Applications

cies in application behavior and in output, and you can clearly measure the
success of the upgrade project.
● With a functionally equivalent application, you will not encounter scope in-
creases or changes, and you can predict and facilitate the testing phases of the
project. You will still need to prepare specifications for any new functionality that
is added after functional equivalence is achieved.
● The goal of achieving functional equivalence gives you a clear, easy-to-under-
stand means of tracking the progress of the project. As you upgrade parts of your
application, you can compare the functionality with the original application.
● A functionally equivalent application eliminates the need for existing users to
adapt to an upgraded application and reduces any change management processes
to the IT department.
● Achieving functional equivalence is the fastest way for an organization to transi-
tion from older to newer technology. It is also the most efficient way for an
organization to regain autonomous control and to resume normal incremental
maintenance of the application.

Application Advancement
Achieving functional equivalence provides you with a working .NET version of
your application, but it is usually considered an intermediate step in the process of
upgrading an application. As described in Chapter 1, “Introduction,” a principal
benefit of upgrading your application to the .NET Framework is that you have
access to significantly improved application performance, integration, productivity,
extensibility, reliability, and security. Using this new technology to add or improve
functionality in your application is referred to as application advancement.
Application advancement involves identifying, and then modifying or extending,
the areas of your application that would benefit from the many improvements that
the .NET Framework offers. In fact, application advancement could be considered to
be the key reason for upgrading to Visual Basic .NET in the first place. However, it
might seem that you are wasting effort by first achieving functional equivalence in
an application that you ultimately plan to change, but by doing this, you are actually
providing a solid basis for a more controlled approach to application advancement.

Organizational Structure and the Software Life Cycle

Whether your upgrade project is focused on functional equivalence, functional
equivalence followed by application advancement, or pure application advance-
ment, you should view the application upgrade as a standard software development
project. Although the design of your application has been determined already (for
the most part) and it is already implemented, you still need to plan for the usual
 Chapter 2: Practices for Successful Upgrades 27

stages of the development cycle. These stages — managing expectations, design,

implementation, and testing — are vital elements in the upgrade process.
While testing is very important to an upgrade project, you might be able to reuse
test processes that you developed for the earlier version of the application. For
example, you may find that some of the testing assets — such test plans, test cases,
and test code — that were used for the Visual Basic 6.0 application are still useful
after the upgrade. This topic is covered in more detail later in the chapter.

Overview of the Upgrade Process

The upgrade of your Visual Basic 6.0 application is not a trivial task. As with any
development project, it is important to have a clear concept of process. This will help
you keep the project on schedule and within your budget.
The process described here was developed as a result of many Visual Basic upgrade
projects performed by Microsoft and its partners. This chapter looks at the upgrade
process as a series of phases that represent milestones within the upgrade. Some of
these phases, such as planning, must be completed for the entire project before any
other phases can start. Other phases can be applied to individual pieces of the
application at the same time while other sections of the application are already in
later phases. For example, if you have chosen a staged upgrade strategy, it is pos-
sible that some of the sections of your Visual Basic application are being prepared
for upgrade while others have already been upgraded and are ready for testing.

Advance

Deploy

Test

Upgrade

Prepare

Plan

Figure 2.1
A graphical representation of the upgrade process.
28 Upgrading Visual Basic 6.0 Applications

The main phases of the upgrade process are planning, preparation, upgrade, testing,
deployment, and advancement. They are briefly described here and will be explored
in more detail later in this chapter:
● Planning. Planning is the first phase of the upgrade project. It involves defining
goals, expectations, and constraints. Planning requires that you assess the appli-
cation to be upgraded so that you can evaluate risks and determine the steps
needed to upgrade the application. It is particularly important for you to deter-
mine the order in which the modules should be upgraded. During the planning
phase, you will also need to evaluate the cost of upgrading the application.
● Preparation. The second phase involves preparing your application for the
upgrade. Although the preparation phase is optional, it is strongly recommended
because by preparing your application in advance you will save a great deal of
time during the upgrade phase. Preparing your application includes modifying
certain implementation details of the application so that the process of using the
Visual Basic Upgrade Wizard is as efficient as possible. This, in turn, reduces the
work you need to do after the upgrade wizard has been used.
● Upgrade. During the upgrade phase, you use the upgrade wizard to upgrade as
much as possible of the Visual Basic 6.0 code to Visual Basic .NET code. After-
ward, you manually upgrade the remaining code. The result of this phase should
be a Visual Basic .NET application that is functionally equivalent to the Visual
Basic 6.0 application.
● Testing. Usually, testing is the basis for demonstrating functional equivalence in
your application. Although listed here as a phase to follow the upgrade phase,
testing should be performed throughout the process, even in the early stages of
the upgrade. For example, unit testing can be applied to individual components
as they are upgraded to ensure they are correct before testing their behavior in
the entire system.
● Deployment. Because deployment also must be tested, the deployment phase
often overlaps with the upgrade and testing phases. This is especially true for
projects that require a successfully deployed application before the testing phase
can be completed.
● Advancement. The final phase involves advancing your functionally equivalent
application by implementing new .NET features or by improving existing fea-
tures with .NET functionality. Keep in mind that any new features will also have
to undergo testing.
Before you begin the project in earnest, you might consider using a subsection of
your application in a test run of this process. A test run can hone your cost estima-
tions and possibly reduce upgrade risks by identifying issues that could block the
progress of the actual project.
 Chapter 2: Practices for Successful Upgrades 29

Proof of Concept
When planning your project, you should evaluate the need to test any major up-
grade issues with a proof of concept or with a prototype. A proof of concept is
evidence that demonstrates whether a project is ideal or feasible. It, or a prototype,
can help you to avoid wasting time on poor coding decisions and can allow you to
validate solutions in an isolated condition. A proof of concept will help you to
determine the real cost of the most common issues that appear in the upgrade
wizard’s upgrade report. For more information about the upgrade wizard, see
Chapter 5, “The Visual Basic Upgrade Process.”
The proof of concept for an upgrade project will help you familiarize yourself with
details of the upgrade process. A good way to develop a proof of concept is by
upgrading a practice application. When choosing a practice application, consider a
simple application that is a good candidate for use with the upgrade wizard and one
that is not tightly integrated with other technologies. (For more information, see the
“Performing an Application Analysis” section later in this chapter). After you have
chosen and then upgraded the practice application, you and your team can gain
valuable experience by analyzing and solving generic issues in the upgraded code.
This activity will help you to identify issues that can affect the execution of your
more complex, real-world project. Learning to upgrade is like learning anything
else: by starting with a simple project, you learn in manageable pieces. Also, because
you will probably have the application upgraded and running quickly, your team
will build the confidence that is needed to tackle a larger project. Finally, this prac-
tice upgrade will help you to assess the feasibility of upgrading a larger, more
complicated application.
If the proof of concept convinces you of the feasibility of upgrading a more complex,
real-world application, choose one that will benefit from the new features of the
.NET Framework so that you can review the process from the point when the appli-
cation has achieved functional equivalence through the final phase of application
advancement. Think about the way the architecture is going to be modified. For
large applications, the principle of divide and conquer applies. You should upgrade
the application module-by-module. For example, you may start with the client
modules, and then move up the dependency hierarchy by next upgrading the
business logic and data tier modules. (For more information about upgrade strate-
gies, see Chapter 1, “Introduction.”) As you move along in the process, be sure that
you test each module of the application as it is upgraded so you know that you have
quality code before you move forward.
After you and your team have had some experience with the upgrade process and
you have chosen a real-world application to upgrade, you will be ready to begin the
work of defining the scope of the project.
30 Upgrading Visual Basic 6.0 Applications

Note: If you plan to upgrade your application one piece at a time, you must apply
interoperability techniques that allow the components that remain in Visual Basic 6.0 to
communicate with the upgraded Visual Basic .NET components. For more information about
interoperability, see Chapter 14, “Interop Between Visual Basic 6.0 and Visual Basic .NET.”

Planning the Upgrade

In addition to the tasks your organization typically performs during a software
development project, your plan for the upgrade project should include the following
activities:
● Defining the project scope. Define the objectives of the upgrade project. Be clear
about which components and features will be upgraded and what you expect
from the upgrade.
● Performing an application analysis. Profile the application you want to upgrade
to determine the best upgrade strategy.
● Assessing the current and the target architecture. Assess the design and imple-
mentation of the application being upgraded. Clarify any architectural aspects
that need to change during the move to Visual Basic .NET.
● Analyzing and designing new functionality. If expectations include functional-
ity that is not in the current application, plan for the analysis and the design of
the new features.
● Selecting an upgrade strategy. Based on the design of your application, you will
probably opt for one upgrade strategy over another. When you make your choice,
you must create measurable milestones and testing processes for intermediate
releases of the application.
● Making an inventory of source code. Specify the amount of source code that
needs to be upgraded. Be sure to include all other dependencies on the applica-
tion that will be required for its compilation and execution.
● Preparing the source code. Plan enough time to prepare the code for the up-
grade. Resist the urge to dive into the upgrade phase before your team or the
code is ready.
● Preparing to handle upgrade issues. Based on the results of your application
assessment, schedule the appropriate amount of time to manually complete
functionality that cannot be fully upgraded by the upgrade wizard. You will also
need to spend time on functionality that was successfully upgraded but may
behave differently in the .NET environment.
● Unit testing. Although this is an upgrade project, you will still need to perform
testing at the unit level to ensure that even low-level code behaves as expected.
Doing this ensures that integration and acceptance testing are more efficient.
 Chapter 2: Practices for Successful Upgrades 31

● Validating functional equivalence and acceptance. If it is necessary for you to

prove that the new application does indeed behave exactly like the original
application — or within a predetermined margin of error — you need to define
the criteria that will be used to measure functional equivalence and application
acceptance.
● Implementing and testing new functionality. Schedule time and resources to
implement and test all new functionality that you will add to the upgraded
application.
● Deploying the Visual Basic .NET application. No upgrade is complete until the
new application has been deployed and is in production. Make the necessary
plans to transition from deploying the original application to deploying the
newly upgraded .NET version.

Defining the Project Scope

Defining the scope of your project is the all-important stage of project planning
where you establish the project goals and the manageable tasks that will accomplish
these goals. You will also define the milestones and criteria that you will use to
measure whether you have succeeded in meeting them.
Upgrade project plans include certain goals that are not usually required in other
software development projects. Primarily, the project scope should include criteria
for measuring whether the upgraded application is functionally equivalent to the
original application.
You need to specify the criteria that you will use to measure the success of reaching
milestones and to prepare the mechanisms that you will use to validate them. Start
by creating test cases. Test cases are an important tool for measuring progress during
the upgrade process and also for measuring functional equivalence. As with any
software development project, test cases help you maintain a level of high quality in
your application.
By answering the following questions, you can further define the scope of your
project:
● Do you expect the first version of the upgraded application to have additional
functionality? Your first aim should be to achieve functional equivalence. If you
want to add functionality, keep this goal separate by defining specific milestones
for the tasks that involve application advancement. Additional functionality is
not an automatic result of upgrading an application; you must plan for it.
● Do you expect to see improvements in the performance of the functionally
equivalent application? Better performance in an application is not an automatic
result of upgrading it. However, performance is a valid requirement for the first
iteration of your upgraded application so these requirements should be well-
documented early.
32 Upgrading Visual Basic 6.0 Applications

● Do you expect improvements in security, usability, or reliability? These im-

provements are additional features that you need to implement after the applica-
tion has achieved functional equivalence. Their implementation is part of
application advancement.
● Do you plan to take advantage of new techniques for deployment and interna-
tionalization? Again, the implementation of these new features is part of applica-
tion advancement and should begin after the application has achieved functional
equivalence.
● Are you aware of new dependencies that come with Visual Basic .NET and the
.NET Framework and how they may affect your deployment requirements? The
deployment of a functionally equivalent application is a reasonable expectation,
and planning for any new dependencies is vital to its success.
● Do you expect the upgraded application to look identical to the original appli-
cation? Are you prepared for differences in appearance? For some types of
applications, there will be unavoidable changes in appearance, so you must plan
to document these changes for users. For information about some of the visual
and behavioral differences you can expect when you upgrade your application to
Visual Basic .NET, see Chapter 9, “Upgrading Visual Basic 6.0 Forms Features.”

Performing an Application Analysis

An important step in managing risk and estimating costs for an upgrade project is
having a team of experts (which may be internal or external to your business)
perform a technical analysis of the application. This will determine the most appro-
priate upgrade strategy for the project. The goal of this activity is to ensure that the
project adapts to your real business needs and that your expectations are realistic
about the outcome of the project. The analysis should produce an outline of the
project’s time and cost estimates, as well as a technical profile of the application.
Both the outline and the profile are imperative to the success of the project.
Begin the profile by identifying and analyzing the application code that will be
upgraded. A good way to start is by producing an inventory of the application
source code, including references to libraries and resources. Then, you need to
identify and classify possible issues that you will have to handle during later stages
of the upgrade. For this task, an initial test run using the upgrade wizard would be
very valuable. When doing this, you may want to distinguish those features in the
source code that will be automatically handled from those that may require manual
intervention or that you might have to consider re-architecting later on as you move
through the process.
As part of the analysis, review the upgrade report that the upgrade wizard pro-
duces. The upgrade report contains information about the upgrade process and a list
of issues uncovered during the upgrade that will need to be addressed before your
project can be compiled and run. Study the different issues in the upgrade report
 Chapter 2: Practices for Successful Upgrades 33

and the solutions that are recommended for resolving them. Remember, you can
reduce the number of issues that need to be addressed by preparing your Visual
Basic 6.0 code before applying the upgrade wizard. For more information about
using the upgrade wizard, see Chapter 5, “The Visual Basic Upgrade Process.”
The purpose of the application analysis is to generate information that will be used
to estimate the effort of the upgrade project and to create a technical profile of the
application. The output of application analysis should cover the following items:
● Current and target architecture

● Inventory to upgrade

● Source code metrics

● Handling of unsupported features

● Assessment of upgrade report information

Assessing the Current and the Target Architectures

As part of the analysis, you will want to clearly understand the current architecture
of the application and the way its components will be replaced in the target architec-
ture. For instance, you may plan to replace ActiveX Data Objects (ADO) with
ADO.NET and COM components with native .NET Framework components. The
resulting target architecture should also include the new components that will
support the new application requirements. These new components are identified as
part of the new requirements analysis and design you create.
It is likely that your upgraded application will interact with other existing Visual
Basic applications, modules, or components, and any portion of the application that
you may decide will be reused but not upgraded. Identify those interactions within
the application architecture and clearly differentiate between the components that
will interact and those that will require interoperability. Also, identify the compo-
nents that can be replaced with equivalent .NET components.

Analyzing and Designing New Functionality

Upgrade projects can be an ideal time to introduce new functionality or features to
an existing application. If there are features that you want to add, document the
requirements for these new features, specify how they will interact with existing
features of the application, and design their inclusion in the upgraded application.
Because this guide is concerned with reaching functional equivalence, details for
analyzing and designing new functionality are not discussed here. However, for
information about possible new features you might consider adding to your applica-
tions, see Chapters 17 – 21 of this guide.
34 Upgrading Visual Basic 6.0 Applications

Selecting an Upgrade Strategy

Chapter 1, “Introduction,” examined the options you have available to you if you
need to update your application. If you decide that an upgrade is the right approach
to updating your application, you should consider the following two upgrade
strategies: a complete upgrade and a staged upgrade.
The complete upgrade strategy suggests that you upgrade all your application as a
whole and not release any code until the entire application is upgraded and running
on the new platform.
The staged upgrade strategy allows you to upgrade some parts of your application
before you upgrade others. This is less risky, but it requires more effort to enable
interoperability between the upgraded and non-upgraded parts of the application.
Do not confuse staged upgrade with partial upgrade, which was discussed in
Chapter 1. A partial upgrade is an alternative to updating an entire application. A
partial upgrade means that you chose to move some of your application or applica-
tions to Visual Basic NET while others remain in Visual Basic 6.0.
After you have chosen to upgrade — whether it is to a partial or a full upgrade —
you can choose to upgrade your application as a whole (complete upgrade) or one
piece at a time (staged upgrade).

Complete Upgrade
With a complete upgrade, all components of your application are upgraded and
deployed as a whole. This does not mean they are upgraded in parallel; it means
only that no effort is made to deploy the application in a production environment
until all components have been moved to .NET. This strategy may require significant
effort, and therefore it can be very expensive. It not only involves upgrading code
from Visual Basic 6.0 to Visual Basic .NET, but also upgrading all of the technologies
to their .NET equivalents when they exist, or applying alternative technologies
when they do not. For applications that do not make significant use of deprecated
technologies, a complete upgrade can be very fast and inexpensive. The more
dependent an application is on dated technologies, the more expensive and time
consuming the upgrade process becomes.
This strategy has the following advantages:
● Upgraded applications can be advanced with new functionality that uses .NET
technologies and techniques. Examples and strategies of this can be found in
Chapter 17, “Introduction to Application Advancement,” Chapter 18, “Advance-
ments for Common Scenarios,” Chapter 19, “Advancements for Common Web
Scenarios,” and Chapter 20, “Common Technology Scenario Advancements.”
 Chapter 2: Practices for Successful Upgrades 35

● Upgraded applications can be integrated into new .NET solutions, making

them usable in more scenarios. This integration can be accomplished regardless
of the programming language used to develop the new application and without
requiring any changes to the existing application.
● Fully-upgraded applications can be used on new hardware and new versions
of Windows. They can be used without requiring any upgrade or recompilation
if the new hardware or the new version of the operating system has a fully
functional .NET Framework engine.
Despite the advantages of complete upgrade, there are also disadvantages, as listed
here:
● Some Visual Basic 6.0 features cannot be automatically or easily upgraded to
Visual Basic .NET. Although alternatives for such features exist in Visual Basic
.NET (and are often better), upgrading this kind of application requires that you
change it to achieve functional equivalence. These changes can be time consum-
ing and costly.
● A completely upgraded application could have a different user interface or
may have different behavior. This will result in the need for complete testing of
the application as a new application. It may also require retraining of users.
● A Visual Basic .NET application requires a compatible version of the .NET
Framework to be installed on target computers. This requires additional plan-
ning and deployment by IT professionals, particularly in large companies.
● Developers responsible for performing the upgrade or for maintaining the
resulting application may have to learn new skills to perform the upgrade. This
has an associated cost in both time and money.
A complete upgrade can be an expensive strategy, but it is often the most desirable
alternative because it positions the application for the future. It is important that you
fully assess your application before making a decision. In many cases, the assess-
ment will demonstrate that the benefits of a complete upgrade far outweigh the
costs, and you will find that moving the application to Visual Basic .NET is the right
decision for your business.

Staged Upgrade
Unlike a complete upgrade, where all pieces of the application are upgraded in a
single complex process, a staged upgrade strategy allows a more controlled, gradual
upgrade where the application is upgraded a part or component at a time. Each
newly upgraded component can be rolled out as it is upgraded, instead of waiting
for the complete upgrade of the entire application. This strategy is only possible
when the existing application is composed of multiple distinct components, each
36 Upgrading Visual Basic 6.0 Applications

developed as a separate project. Also, interoperability techniques must be applied

for the upgraded and unchanged components to function together.
A staged upgrade provides a reasonable compromise to a complete upgrade. Staged
upgrades are likely to be the best alternative for large-scale legacy applications. This
strategy has the following advantages:
● Upgrading the application in stages allows you to have more control over the
progress and the cost of the upgrade project and allows you to minimize risk
because you returns the application to a stable production-quality state after each
stage. Because your development team will gradually become better acquainted
with .NET at each stage, their productivity will improve — as will your estimates
of effort and cost.
● Upgraded components can often immediately benefit from the performance and
scalability features of .NET, without having to wait for the entire application to be
upgraded.
● Upgrading of the low priority or costly portions of an application can be post-
poned indefinitely, resulting in a partial upgrade. A staged approach like this
effectively gives you the freedom after the upgrade project has begun to opt for a
mixed upgrade/reuse solution as described in the “Upgrade, Reuse, Rewrite, or
Reuse?” section in Chapter 1, “Introduction.”
The disadvantages of staged upgrade include the following:
● Performance improvements will not be as noticeable as in a full upgrade because
of the added overhead required for COM interoperability. COM interop between
.NET components and COM components is not as fast as managed components
working together in the .NET Framework or COM objects in Visual Basic 6.0
working together. However, the difference in performance should only be notice-
able in applications that perform a large number of COM method calls, such as
those with tens of thousands of transaction requests.
● Applications with a dependency on COM components are harder to deploy and
maintain than applications that are fully upgraded to .NET because COM objects
need to be registered and have versioning issues that .NET objects do not.
● A staged upgrade requires the implementation of wrappers or interfaces to
provide the interoperability mechanisms between the .NET and the legacy code.
These wrappers will often be temporary and will be discarded later.
Despite the disadvantages, staged upgrades may be the most appealing strategies
for large-scale applications with multiple components.
Staged upgrades can be further classified as vertical and horizontal:
● Vertical upgrades. These involve isolating and upgrading all n-tiers of a single
module of your application without modifying other parts of the application.
● Horizontal upgrades. These involve upgrading an entire tier of your application
without modifying the other tiers.
 Chapter 2: Practices for Successful Upgrades 37

Whether you choose a horizontal or a vertical approach to a staged upgrade will

depend on the architecture of your application. Therefore, the solution architects in
your team should be highly involved in the selection of the strategy. You also will
find advantages and disadvantages to each strategy based on the application you
are upgrading. Usually an assessment of the design and implementation of the
application will point to the best strategy to adopt.
The next sections examine the horizontal and vertical upgrade approaches to help
you choose the one most suitable for your application’s architecture.
Vertical Upgrade
In the vertical upgrade strategy, one or more of the application components that cut
through several, if not all, application tiers are identified and selected to be up-
graded. Essentially, this involves extracting a piece of your application that has
minimal interaction with other pieces and upgrading it independently of the rest of
the application.
If parts of your application are well isolated from others, you have an outstanding
candidate for a vertical upgrade. An ideal candidate will typically share very little
state information with the rest of the application and can easily be upgraded with
little impact on the rest of the system.
The following scenarios describe application architectures that are well suited to the
vertical upgrade strategy:
● Application tiers are tightly integrated. If you make heavy use of ADO
recordsets between tiers, a vertical upgrade is worth examining. Many applica-
tions pass disconnected ADO recordsets from the data and business tiers to the
presentation tier. The presentation tier then iterates through the recordsets and
generates HTML tables. This type of application is well suited to a vertical
upgrade because you can focus on specific aspects of the application individually.
For example, an ADO to ADO.NET upgrade and interoperability requires special
consideration. Upgrading vertically can minimize the work involved in achieving
interoperability with ADO.
● You are planning to redesign the application. Vertically upgrading parts of your
application to new architecture provides a good test bed for a new application
design. The .NET Framework makes it easier to provide the functionality that
newer architectures are built on. For example, you can use HttpHandlers to
perform many of the tasks that you would previously use ISAPI extensions for,
but with a much simpler programming model.
After the chosen portion is upgraded, any remaining interfaces between the new
managed code and the unmanaged code will function through COM
interoperability. You will need to do some development and testing to make sure
that the new and old pieces of the application work together, share data, and pro-
vide a seamless experience to the end user or client developer. Afterwards, you will
38 Upgrading Visual Basic 6.0 Applications

have the basic infrastructure that will make it possible to continue with the upgrade
of other applications using the same vertical approach — or to extend the updated
portion of the original application.
Horizontal Upgrade
In a horizontal upgrade strategy, you upgrade an entire tier of your application to
Visual Basic .NET without immediately upgrading the other tiers. By upgrading a
single tier at a time, you can take advantage of the specific features that the .NET
Framework provides for that particular tier, in many cases without modifying
application code or affecting the operation of other application tiers. Deciding which
tier to upgrade first is the first step in a horizontal upgrade strategy.
Middle-tier COM components can be upgraded to Visual Basic .NET with few or no
changes to the presentation tier. You should consider the following points when
deciding if a horizontal upgrade strategy is appropriate, and if so, which tier is the
most suitable to upgrade first:
● Your application is on a large number of Web servers. A prerequisite for the
deployment of a Visual Basic .NET application is that the common language
runtime (CLR) must be installed on each Web server. If your application is de-
ployed on a large number of servers in a Web farm configuration, this can be an
issue. If you have relatively fewer servers in middle tiers than in other tiers,
consider using a horizontal upgrade and then upgrading the middle tier first.
● Your application uses a large amount of shared code. If your Visual Basic
application uses a large number of DLLs or other types of shared code, constants,
or custom libraries in the middle tier, choosing to upgrade this tier first can help
you manage the upgrade of your entire application. However, if you do this, you
will destabilize a large number of components that use the shared code and
thereby affect the testing process.
● Your application has a complex middle tier. Complex object hierarchies in the
middle tier should be kept as a unit. Deciding where to isolate an application
with a complex middle-tier object hierarchy is difficult, and upgrading only parts
of a complex middle tier typically necessitates numerous interoperability calls
between environments, resulting in performance degradation.

You should also consider the following issues when replacing the middle tier:
● To transparently replace middle-tier components with .NET components without
affecting client code, you must maintain the original GUIDS and ProgIDs of your
COM components. In addition, you must properly handle replacement of the
class interface generated by Visual Basic components when you attempt to
transparently replace a COM component.
● You will have to translate the ADO.NET datasets that are returned from your
upgraded middle-tier components to ADO recordsets that are used in your
original Visual Basic code.
 Chapter 2: Practices for Successful Upgrades 39

● You will need to deploy the interoperability assemblies for the middle tier com-
ponents.
● Interoperability between Visual Basic .NET and Visual Basic 6.0 can become
prevalent in this type of upgrade, depending on how you choose to define the
application tiers. If the distance between the tiers is widened by making one side
of the communication a .NET assembly, you may be increasing the amount of
marshaling that is occurring in your application, which can negatively affect
performance.
After you decide on an upgrade strategy, you can increase the efficiency and chance
for success in the upgrade process by producing a project plan for the upgrade. For
more information, see the “Producing a Project Plan” section later in this chapter.

Testing
To make sure that your application achieves functional equivalence regardless of the
upgrade strategy you choose, you need to produce comprehensive unit and system
test plans for the entire system, as well as for individual upgrade modules and tiers.
For detailed information about testing in upgrade projects, see Chapter 21, “Testing
Upgraded Applications.”

Making an Inventory of Source Code

Identify the relevant source code that will be upgraded. This should include librar-
ies, resources and components. You can use the application’s Call Graph view to
make a dependency diagram in the form of a tree view to help you recognize the
relevant Visual Basic 6.0 projects and files. For any dead code you find, you will
need to decide to make it part of the inventory or exclude it partially or entirely.
Tools such as the Visual Basic 6.0 Upgrade Assessment Tool can help you identify
dependencies and dead code in your source code. For more information about these
tools see Chapter 5, “The Visual Basic Upgrade Process.”
In addition, identify the application components that will be upgraded and any that
will be left alone and reused, including all of the components that the application
currently uses. In the case of third-party components, determine the availability of
existing .NET equivalents.

Preparing the Source Code

Investing time to prepare your source code for the upgrade will increase the effi-
ciency of the upgrade project. For information about how to do this, see the “Prepar-
ing the Visual Basic 6.0 Source Code” section later in this chapter.
40 Upgrading Visual Basic 6.0 Applications

Preparing to Handle Upgrade Issues

If you identify potential issues before you begin the upgrade, you will be better
prepared to address them during the upgrade process than if you wait until you are
deeply involved in implementing the upgrade changes. This section provides
guidance on how to obtain the information you need to help you build a catalog of
issues.

Obtaining Source Code Metrics

Obtain metrics information from the application source code. This information
should include size metrics, such as the number of lines of code, projects, forms,
designers, modules, classes, components, user controls, data sources; and usage
metrics, such as functions, properties and events used.
You also need to obtain metrics on how frequently each component is used in the
application. Knowing in what way and how frequently a component is used helps to
determine whether you can replace each component with an equivalent .NET
version after the application has been upgraded.
Figure 2.2 shows partial source code metrics for a sample stock management appli-
cation. It gives information about the source code inventory.

Figure 2.2
Partial source metrics for a stock management application

The figure shows partial information about data types and controls occurrences, the
source code inventory (in the form of a tree view), and the location of specific uses of
data types; in this case the Integer and String types. The assessment tool provides
all this information in easy-to-read HTML reports. For more information about the
assessment tool, see Chapter 3, “Assessment and Analysis.”

Identifying Unsupported Features

Identify all of the Visual Basic 6.0 features that are not supported in Visual Basic
.NET, and note how often they are used in the application. You should investigate
and make prototypes of Visual Basic .NET functionality that could replace these
unsupported features. This is also a good time to identify where additional function-
ality is needed. For more information about early version and obsolete Visual Basic
6.0 features and the alternatives that are available in Visual Basic .NET, see Chapter
 Chapter 2: Practices for Successful Upgrades 41

7, “Upgrading Commonly-Used Visual Basic 6.0 Objects”, Chapter 8, “Upgrading

Commonly-Used Visual Basic 6.0 Language Features,” and Chapter 9, “Upgrading
Visual Basic 6.0 Forms Features.”

Assessing the Upgrade Report Information

After you run the upgrade wizard on your application, it generates a report that
identifies the upgrade issues it encountered and the number of times that they occur
in the application. Each type of issue is identified by an issue number, a description,
a link to related documentation, and the steps you can take to possibly resolve the
issue. For example, the issue number 1037 corresponds to the issue “Late-bound
default property reference could not be resolved,” and the report will link you to
documentation for resolving this issue.
The following list summarizes the most probable causes for common issues identi-
fied in the upgrade report:
● A small number of Visual Basic 6.0 core functions have no direct .NET equivalent
or core Visual Basic 6.0 functions behave differently when they are upgraded.
However, even for the few functions that have no direct equivalent or those that
behave differently when the are upgraded, Visual Basic .NET provides alterna-
tives for achieving the same functionality in your application. These alternatives
typically require manual modification of the code and cannot be automatically
upgraded.
● Certain ActiveX controls are not supported in Visual Basic .NET.

● The upgrade wizard found language changes in the upgraded code and prompts
you to manually review them. An example of this is the case default properties in
Visual Basic 6.0. Whenever possible, the upgrade wizard will resolve default
properties and explicitly expand them in the upgraded code; however, you
should review these expansions to verify that the correct property was substi-
tuted for the default property in the original code.
A useful way to begin to analyze the upgrade issues in your application is to orga-
nize them into the following two categories:
● Not upgraded and unsupported issues. These issues indicate the presence of
unsupported features, the use of control properties or methods, or the existence
of statements that require manual intervention. All of the issues in this category
prevent successful compilation of the upgraded application. After unsupported
features are addressed, the vast majority — as much as 95 percent — of the
remaining issues in this category are resolved by using simple code analyses to
find solutions in Visual Basic .NET. For example, some classes and methods of the
COM+ interface, such as ObjectContext and Commit are not upgraded. Equiva-
lent members and functionality can be found in the .NET namespace
EnterpriseServices. The remaining 5 percent of the issues require either minor
changes in the application logic or in the implementation of supporting function-
ality.
42 Upgrading Visual Basic 6.0 Applications

● Different behavior issues. These issues indicate that the upgraded code might
have behavior that differs from the original behavior in the Visual Basic 6.0
application. With these issues, you should manually review the possible conse-
quences of the new behavior under the code context because you may need to
modify the code. Issues in this category do not prevent the upgraded application
from compiling successfully, but they may produce run-time errors and cause the
upgraded application to fail. Experience with this category of issues has shown
that only a few of them require manual intervention. Their descriptions can also
provide guidance during unit testing of the upgraded application by describing
the behavioral differences. By using this information, testers will know what
behavioral differences to expect and can test whether or not the differences break
the functional equivalence of the upgraded application. For this reason, you
should not remove them from the code until after application has been success-
fully unit-tested.
For each category, note the different issue numbers and the frequency of their
occurrence. Beginning with the most frequently occurring issues, determine the best
solution and the effort required to resolve them. Because these issues occur the most
frequently, you should work on them first. Next, determine solutions and effort
estimations for any remaining not upgraded or unsupported issues. Then, finish up
by determining the resolution and effort required for issues that relate to behavior
differences. Not upgraded and unsupported issues are usually more critical to
resolve than behavior-related issues. A practical way to estimate how much effort is
needed to resolve an issue is to perform a test run of the upgrade where many of the
issues can be resolved, and use data from this experience as a benchmark.

Producing a Project Plan

As with traditional software development projects, it is important to plan and
schedule time for the following phases of an upgrade project:
● Project management (administrative tasks)

● Training for the upgrade process and for .NET

● Setting up the development environment, including setting up databases,

organizing source code, and installing necessary applications
● Code preparation

● Performing the upgrade process

● Converting and validating test cases

● Code and unit testing

● Functional testing

● Transferring information and the deployment of upgraded code

 Chapter 2: Practices for Successful Upgrades 43

As with any software development process, carefully plan and schedule so that you
can meet the milestones for each deliverable. This will help you to manage the
expectations of your internal and external customers. Also, be sure that when you
schedule your upgrade project, you consider the rest of the projects being conducted
within your company to ensure that your project has the IT support it needs.

Estimating Cost
Estimating the cost requirements for a software development project is typically a
complex task because of the wide range of quality in software implementation and
the varying programming abilities of developers. Estimating the cost requirements
for an upgrade project is no different. Many factors affect the amount of effort that
will be required to upgrade an application. Similarly, these factors affect the cost of
the application; therefore, estimations for cost will vary widely depending on the
application.
Some factors that affect cost estimations are common to all upgrade projects. These
common factors include:
● The methodology of the Visual Basic 6.0 code; whether the code was written in an
object-oriented fashion, the extent that it relies on a common set of services
shared across a family of applications, and the interdependencies between parts
of it that will be upgraded and parts that will remain in Visual Basic 6.0.
● The maintenance history of the original code. Applications with a history of
requiring frequent fixes are likely to require frequent fixes during the upgrade.
● The complexity of the application requirements.

● The degree to which the application is integrated with other systems.

● Security considerations.

● The size and experience of your development team.

● Any third-party toolsets that are used within the application.

● The testing infrastructure and commitment to quality control.

Other factors that could affect your cost estimation are specific to the code and the
platform of the application. Factors such as the use of mechanisms and constructs
such as RDO/DAO data binding, late-bound objects and ActiveX documents affect
estimations of cost. For ASP code, factors include the use of render functions (as
opposed to Response.Write), the use of multiple languages per page, the use of
nested include files, reliance on 16-bit integer size, default parameters, and GOSUB,
among other specifics.
44 Upgrading Visual Basic 6.0 Applications

The following tasks will also affect the final estimations for the costs of your up-
grade project:
● Resolving unsupported features. It is necessary to estimate the costs for different
issues that affect unsupported features. These issues include:
● The research costs for alternative solutions.

● The costs of developing and testing the chosen solution.

● The cost of replacing an unsupported feature increases the more it is used in

an application. It will increase depending on the particular feature and how it
is used. Multiple uses of a feature might need individual attention or in some
cases may be resolved by simply using a find-and-replace mechanism.
● Resolving reported issues. For every issue in the upgrade report, you need to
estimate the cost to resolve it. A good way to estimate these costs is to perform a
test run of the upgrade. By testing the upgrade of a select portion of the applica-
tion you will see an example of the type of issues that the upgrade wizard will
find. With this information, you can then obtain accurate information on the cost
of resolving the issues. The test run will also provide valuable insight into your
team’s capabilities in the upgrade process.
● Testing. You need to estimate the cost of testing the upgraded application. A test
run (mentioned in the previous bullet) will provide valuable information on the
testing requirements that you will need. By doing a test run you can evaluate
whether your current testing processes will work, or if they need extensions or
adjustments to certify that the upgraded application has achieved functional
equivalence. You will also need to estimate the cost of testing additional function-
ality that will be implemented during the application advancement phase of the
project.
Also, realize that because you will be testing the entire upgraded application and
not just new features (as you might do for an application that is being updated)
the testing process can take longer and possibly require several iterations, which
will increase your usual costs for testing.
● Manually replacing Visual Basic 6.0 components with .NET equivalent compo-
nents. For each Visual Basic 6.0 component that cannot be automatically replaced
with a .NET equivalent by the upgrade wizard, you will need to estimate the cost
of manually replacing it. When you do this, be sure to consider the frequency that
this feature will appear in the upgraded application.
● Third-party .NET components. From each third-party component that your
application relies on, you will need to obtain the license cost of the .NET compo-
nent that you plan to use a replacement in the upgraded application.
● Secondary features. If your application has secondary features such as an inte-
grated help system, an installer, and manuals, you will need to consider the costs
of adding these to your new application.
 Chapter 2: Practices for Successful Upgrades 45

● Deployment. Estimate the cost of deploying the upgraded application.

● New requirements. You will need to estimate the costs of designing, developing
and testing new features that you want to add after the application has been
upgraded. Estimating the cost for the application advancement phase of the
project is comparable to estimating the cost of a typical software development
project.
A sensible way to estimate the cost for upgrading an application is by using your
organization’s experience in estimating the costs for traditional software develop-
ment projects. Clearly, traditional development projects also consider general and
specific factors, such as the ones previously mentioned, to ensure success. When
estimating the cost for an upgrade project, keep in mind that some typical project
phases may not be required and should not be included in your cost estimates.
For example, traditional software development projects include phases such as
analysis, design, development, testing and deployment. In an upgrade project
common phases usually include a shorter analysis phase in addition to the upgrade,
testing, and deployment phases. The typical analysis and design phases are rarely
needed because the source code itself is the specification.
Cost estimations for the upgrade phase of the project are based primarily on the
output of the application analysis: the cost of solving different upgrade issues found
during the application analysis. If appropriately addressed, solving these issues
should be much less expensive than rewriting code. Pay special attention to the
impact that non-supported, or obsolete features of the application may have on your
costs. You can minimize these impacts by preparing or cleaning up the source code
before proceeding with the upgrade process. Additionally, make sure you assess
carefully the abilities of developers to handle upgrade issues.
Estimating the cost of the testing phase of an upgrade project primarily depends on
the quality and the status of the infrastructure that will be used to test the applica-
tion, or the portions of the application that will be upgraded. Remember that achiev-
ing functional equivalence is directly related to test cases being able to certify the
expected behavior of the upgraded code and will typically define the project accep-
tance criteria. Therefore, if automated testing is available, consider any work needed
to revise it so that it runs on the .NET Framework. Allocate budget resources to
extend testing coverage where it is needed. Also, understand the depth of testing
that the upgraded .NET application might require in contrast to the usual (possibly
localized) testing performed on a Visual Basic 6.0 release. You may find that apply-
ing your full regression test cases to the upgraded application can take longer and
require several testing iterations, which might affect the usual testing costs. In
general, testing costs have two parts: creating the test cases and running them.
Because the goal here is achieving functional equivalence, the test case creation
46 Upgrading Visual Basic 6.0 Applications

phase can be skipped if your original tests cases are adequate and it is only neces-
sary to adapt them to the new platform. As for any development project, the execu-
tion of test cases must be done in an iterative way as you get closer to completing
the project.
Finally, estimating costs for the deployment phase of an upgrade project is compa-
rable to the deployment costs of traditional software development projects. Of
course, you need to train your team to understand and deal with the issues of .NET
deployment. The good news is that generally, .NET deployment consists of a much
more streamlined mechanism than COM-based applications.
Using the information in this section as a guide, you should be able to estimate costs
for the work-hours that are required for the upgrade project. After you complete the
first estimate, you can further refine the figures and make adjustments as necessary.
This process can also apply to the upgrade plan. When you estimate project costs in
this way, you will notice that the main difference in expenditures for a traditional
software development project and those for an upgrade project involve the testing
phase. The testing process for a traditional project represents approximately 20
percent to 30 percent of the total cost. The testing process for an upgrade project can
easily represent 60 percent to 70 percent of the total cost. However, the overall work-
hours required for an upgrade project are considerably fewer than those required for
a traditional software development project.
Upgrade tests performed by Microsoft and its partners found that when code is
adequately prepared prior to the upgrade, the cost of upgrading from Visual Basic
6.0 to Visual Basic .NET is typically 15 percent to 25 percent of the total development
cost. This figure takes into account the learning curve of Visual Basic developers
who move from Visual Basic 6.0 to Visual Basic .NET. The next section investigates
how to best prepare your application for the upgrade.

Preparing for the Upgrade

After finish the planning stage of the project, the actual implementation of the plan
will begin. The first step in the implementation of this plan is not necessarily a head-
first dive into applying the upgrade wizard, and then resolving the individual
errors, warnings and issues (EWIs) produced by this tool. Although this will work, it
is not the best course for upgrade projects other than those that involve the simplest
of applications.
More complex applications will benefit from the initial preparation of searching the
source code for specific and common practices (such as the use of default properties)
and then modifying the code. The modifications allow the upgrade wizard to
understand the code more easily and as a result, make much better decisions about
correctly translating the code to Visual Basic .NET. At first glance, this preparation
 Chapter 2: Practices for Successful Upgrades 47

may seem like additional work, but in the end, these early modifications will save a
great deal of work.
Before preparing the source code for the upgrade, it is important to first prepare the
development environment that you will use to upgrade the application.

Preparing the Development Environment

This section describes the basic set of tools that are needed by the developers who
will work on the upgrade of the application. The tools are introduced in this section
and some are described in more detail in other chapters. The introductions identify
the tools you need, explain why the tools are needed, and where to get more infor-
mation about the tools.

Visual Studio 6.0

Visual Studio 6.0 will be needed to prepare the Visual Basic 6.0 code for the upgrade
and to ensure that the code will compile before you upgrade it using the upgrade
wizard. This IDE can be installed on any computer without conflicting with the
other tools you will need for the upgrade.
During the preparation of the source code, you will use a list of tasks that will have
been produced by the Visual Basic 6.0 Code Advisor, as discussed later. These tasks
involve modifying the source code and then recompiling. All this work must be
performed inside Visual Studio. NET.
With Visual Studio 6.0 source code, you will use a list of tasks that will have been
produced by the Visual Basic 6.0 Code Advisor, as discussed later. These tasks
involve modifying the source code and then recompiling. All this work must be
done inside Visual Studio 6.0.
It is also quite common to run the upgrade wizard, review the upgrade report, and
then to return to the Visual Basic 6.0 to make further modifications.
Although these tasks can be performed on a different computer, you may find it
more convenient to do it all on a single computer, especially if you find yourself
switching between the original code and the upgraded code.

Visual Basic 6.0 Code Advisor

The Visual Basic 6.0 Code Advisor is an add-in for Visual Studio 6.0. It can be used
to scan your Visual Basic 6.0 source code for practices that do not comply with
configurable coding standards. These standards are based on practices developed by
Microsoft to produce robust and easy-to-maintain code. The code advisor will also
highlight issues in your code that make it difficult for the upgrade wizard to auto-
matically convert your code to Visual Basic .NET.
48 Upgrading Visual Basic 6.0 Applications

The code advisor must be downloaded and installed on your computer before you
can use it. It is not installed automatically with Visual Studio 6.0. For more informa-
tion about the code advisor, see Chapter 5, “The Visual Basic Upgrade Process.”

Visual Studio .NET

Microsoft Visual Studio .NET is the development environment that you will use to
develop and maintain Visual Basic .NET applications. You will also use it to run the
upgrade wizard that will convert your Visual Basic 6.0 projects to Visual Basic .NET
projects.
Visual Studio .NET is an advanced integrated-development environment that has
many new and improved features that were not available in Visual Studio 6.0, as
well as most of the features that you are used to.
You can build applications for multiple languages and platforms within the same
IDE and even within the same workspace or solution. You can build applications in
Visual C++, Visual Basic .NET, Visual C#, and Visual J# for desktops, servers, the
Web, and mobile devices. There are also great new features that ease deployment
such as built-in Windows Installer technology for both Windows and Web deploy-
ment. Maintenance has never been easier with features, such as side-by-side applica-
tion execution that cuts down on, or even eliminates, DLL versioning issues.
Another big addition to this version of Visual Studio is the support for Web services.
Creating a Web service requires only a little more effort than any other class in
Visual Basic .NET. The advanced support for deploying and debugging Web services
allows you to focus your efforts where they are most valuable: on building your
application.
A feature that is not available in Visual Studio .NET is Edit and Continue. This
feature allowed you to modify code in the debugger as you continue to run the
application with the new code without having to restart the application. This feature
is very helpful in Visual Basic 6.0 because you can efficiently make small changes to
code during debugging. This feature will be added to a future version of Visual
Studio.
For more information about Visual Studio, see the Microsoft Visual Studio Devel-
oper Center on MSDN.

Visual Basic Upgrade Wizard

The Visual Basic Upgrade Wizard is the tool that you will use to perform the auto-
matic steps of converting your Visual Basic 6.0 source code and project files into
Visual Basic .NET. The upgrade wizard is built into Visual Studio 2003 and runs
automatically when you try to open a Visual Basic 6.0 project. There are no special
steps required to install or run it.
 Chapter 2: Practices for Successful Upgrades 49

For more information about the upgrade wizard, see Chapter 5, “The Visual Basic
Upgrade Process.”

ASP to ASP.NET Migration Assistant

The ASP to ASP.NET Migration Assistant is an add-in to Visual Studio .NET that can
be used to help you upgrade your ASP pages and applications to ASP.NET.
This migration assistant will rename files, update hyperlinks, and it will also fix
syntax differences in the VBScript between ASP and ASP.NET. It will also attempt to
resolve the correct type of any variable that is not explicitly typed in VBScript code
and therefore relies on late-binding to resolve default properties that are not sup-
ported in ASP.NET.
For more information about the migration assistant, see Appendix C, “Introduction
to Upgrading ASP.”

Preparing the Visual Basic 6.0 Source Code

Almost without exception, if you take steps to prepare your application in Visual
Basic 6.0 before upgrading it, the process will be more efficient. Certain common
practices in Visual Basic 6.0 produce code that is correct and humanly readable but
that the upgrade wizard cannot appropriately convert into Visual Basic .NET.
Several tools can be used to provide a list of issues that will come to your attention
when you pass your code through the upgrade wizard. Such a list can help determine
areas of your code that may be easier to modify in its original source code, especially
if your developers know Visual Basic 6.0 better than they do Visual Basic .NET.
The Visual Basic 6.0 Code Advisor, described earlier in this chapter, should be the
first tool that you use when you start preparing your application for the upgrade.
The second tool should be the upgrade wizard. It produces a report that contains
all of the errors, warnings, and issues that it finds during the upgrade. The report
frequently includes issues that the code advisor does not identify. Addressing the
issues indicated by the upgrade report may require several iterations to best prepare
the source code before you can achieve functional equivalence. Frequently, several
issues reported by the upgrade wizard are related to the same problem that when
fixed, simultaneously eradicates many other issues. For example, if you use the
default property in a late-bound variable, specifying the type of the variable explic-
itly will remove all issues related to the use of the default property. Experience using
the upgrade wizard shows that, on average, fixing a single issue in the Visual Basic
6.0 source code prior to the upgrade resolves five to eight issues that the upgrade
wizard would have reported. Figure 2.3 on the next page shows a graphical repre-
sentation of the iterative process for modifying code based on suggestions in the
upgrade report.
50 Upgrading Visual Basic 6.0 Applications

For more information about how to prepare your code for the upgrade, see Chapter
5, “The Visual Basic Upgrade Process.”

Code Advisor
Report

Modify

Upgrade
Report

No Ready for
Upgrade

Yes

Figure 2.3
A graphical representation of the code preparation phase

Upgrading Applications Written in Earlier Versions of Visual Basic

The upgrade wizard is designed to upgrade Visual Basic 6.0 applications. For
projects written in Visual Basic versions 1.0 through 5.0, it is necessary that you first
upgrade them to Visual Basic 6.0 before upgrading to Visual Basic .NET. To upgrade
a project that was developed in a version earlier than Visual Basic 6.0, simply open
the project in the Visual Basic 6.0 IDE and save it. If Visual Basic 6.0 prompts you to
upgrade controls to Visual Basic 6.0, choose Yes. If the project contains Visual Basic
5.0 ActiveX controls, it is often best to replace these controls with Visual Basic 6.0
versions. This is because these controls use a different threading model than models
used by Visual Basic 6.0 controls. The earlier threading model is not supported in
Windows Forms.
For 16-bit projects written in Visual Basic versions 1.0 through 4.0, you may need to
make extra modifications to the application to convert it to Visual Basic 6.0. Some
 Chapter 2: Practices for Successful Upgrades 51

VBX controls will not be automatically converted. You will also have to replace
Win16 Windows APIs with their Win32® counterparts.
Visual Basic versions 2.0 and 3.0 often require an extra step. Visual Basic 6.0 can only
open files in text format, whereas Visual Basic versions 2.0 and 3.0 support two file
formats: binary and text. Before upgrading these projects, ensure the entire applica-
tion is saved in text format by using the following procedure.

To convert Visual Basic 1.0 and 2.0 files to text format
1. On the File menu, click Save As.
2. In the Save dialog box, select the Save As Text check box.
Because Visual Basic 1.0 can only save files in binary format, all of these projects will
first need to be opened in Visual Basic 2.0 or 3.0 and then saved as text before they
can be converted to Visual Basic 6.0. After converting the project to Visual Basic 6.0,
you can begin the process of upgrading it to Visual Basic .NET.

Verifying Compilation
The upgrade wizard is designed to work with valid Visual Basic projects, so it is
very important to verify that the code is syntactically correct before trying to up-
grade it. If files have errors the upgrade wizard might have problems when it is
trying to parse the code and you may get some misleading error messages or, worse,
unexpected results. Correct syntax can be verified by compiling the Visual Basic 6.0
project before applying the upgrade wizard.
This also helps you ensure that all the necessary source code is available. The up-
grade wizard first analyzes all the code, and then uses the information it obtains to
make decisions. It then starts the conversion of the code. If there are missing files,
some of the decisions that the upgrade wizard makes may prove to be incorrect.
Compiling the original source base in Visual Basic 6.0 before applying the upgrade
wizard will help ensure that the tool will have all the information it needs to make
the best choices possible. The better the decisions the upgrade wizard makes, the
less manual intervention will be required to achieve functional equivalence.

Upgrading the Application

After the code is prepared, it is time to convert the code and produce the function-
ally equivalent .NET application. This is done in two steps.
First, you use the upgrade wizard to load the prepared Visual Basic 6.0 code into
Visual Studio .NET. If you have prepared your application as outlined in the previ-
ous section, this step will be almost effortless because any issues of missing files or
compilation problems are resolved. The code that is produced by the upgrade
wizard during this step will be used as the baseline for all further development of
52 Upgrading Visual Basic 6.0 Applications

the upgraded application. At this point, the generated code is referred to as green
code because it is fresh out of the upgrade wizard and has not yet been manually
modified.
In the second step, you modify the green code so that it will compile and replace all
remaining code that was not completely upgraded with valid Visual Basic .NET
equivalents. Samples of the kinds of modifications that are necessary are listed in the
“Preparing to Handle Upgrade Issues” section earlier in this chapter.
For more information about these two steps, see Chapter 5, “The Visual Basic Up-
grade Process.”
After the application successfully compiles and all issues that were reported by the
upgrade wizard have been addressed, you are ready to begin testing. Testing is
discussed in the following section.

Testing and Quality Assurance

Testing ensures that an application and its components behave according to their
individual specifications. Does your program do what is expected of it? Does it
perform as fast and as well as expected? A good testing process will ensure all of
these requirements are met.
Continuous testing is a vital part of software development. This is equally true in an
upgrade project. Continuous testing allows you to find bugs early, it can prevent the
reappearance of bugs, and it can create confidence in the software and the develop-
ment effort because developers can be sure that they are not introducing new bugs.
All of this saves time and money, and increase customer satisfaction because cus-
tomers experience fewer bugs when they receive the final product.
Any change to code has the possibility of introducing bugs. As the application is
upgraded and the new version evolves, you will need an appropriate set of regres-
sion tests to guard against bugs.
For detailed information about testing your upgraded application, see Chapter 21,
“Testing Upgraded Applications.”

Deployment
After you have upgraded and tested your Visual Basic .NET application, it is time to
start the deployment of the completed application. The main objective of deploying
.NET applications is the same as deploying Visual Basic 6.0 applications: you need to
install your application and get it running on the client’s computer or on the produc-
tion servers. However, the way you do this, the dependencies that your application
has, and the mechanisms for handling updates and security have all changed. The
 Chapter 2: Practices for Successful Upgrades 53

reason for this is the .NET assembly — the new packaging mechanism for .NET
applications.
The primary new dependency that you will have to confirm when deploying your
.NET application is whether the .NET Framework is installed on the target comput-
ers. If there is a chance that the .NET Framework is not installed on the target
computers, you should consider providing a way for your users to install it.

Assemblies
The smallest deployable unit of a .NET application is called an assembly. An assem-
bly is a collection of classes, configuration files, resource files, and any other files
that your application needs at run time. An assembly can be an executable (EXE) or
a dynamically linked library (DLL).
What makes an assembly different from previous types of executable files and DLLs
is that the assembly contains extra information, called metadata, about itself and
about the classes it contains. Among other things, the extra information that an
assembly contains helps distinguish different versions of the same assembly.
The assembly also contains security related information that can ensure that the
assembly comes from who you think it comes from and that it has not been modified
since the original creator released it.

Private and Shared Assemblies

By default, assemblies are installed into the same directory as the owning applica-
tion. This type of assembly is called a private assembly. Because it is installed in the
application directory, there is no chance of it interfering with other applications
installed on the same computer.
You can also create shared assemblies that are installed into a system wide reposi-
tory for assemblies called the global assembly cache. These assemblies can be used
by multiple independent applications. The advantage of these assemblies is that
they use less disk space and less memory.

Versioning
You can easily install multiple versions of the same assembly in the global assembly
cache and the global assembly cache will maintain these assemblies separately.
These versions can have the same name and the same GUID (for exposure to COM)
but have different versions. The .NET Framework will ensure that only the version
of the assembly that your application was compiled against will be linked to it at
run time. For you to change the version of a DLL that an application uses without
reinstalling the application, you need to insert special directives into the configura-
tion file for that application. This installs an incompatible version of a DLL, thereby
54 Upgrading Visual Basic 6.0 Applications

effectively eliminating the problem of new applications interfering with applications

that are already on your computer.
The global assembly cache also distinguishes assemblies that have the same version
but were compiled for different architectures or different processors. For example,
you can install the same .NET assembly for 32-bit and 64-bit platforms and the
global assembly cache will automatically choose the most suitable assembly for your
application. You can even optimize your assemblies for different models of 64-bit
processor and the global assembly cache will automatically pick the one that is most
appropriate.

Side-by-Side Execution
The benefit of allowing different versions of the same assembly to be installed on
the same computer and shared by different applications is that you can now easily
install multiple versions of your .NET applications on the same computer and allow
them to run side by side without interfering with each other.

Configuration
Deployment and side-by-side execution are also facilitated by the fact that .NET
applications do not need to keep any configuration information in the Windows
registry. This eliminates the registry as a source of collisions between different
versions of an application.
Configuration information for .NET applications is kept in XML-based configuration
files in the same directory as the application itself. Another file exists that applies to
all the versions of the same application, while a third exists at the computer level.

Update Deployment
As previously mentioned, an installed application will only normally link to the
same version assembly that it was compiled against. However, it is possible to add a
configuration setting to the application’s configuration file to tell it to stop using the
version of a DLL that it was installed with and to start using an updated DLL. This
redirection can only occur with explicit redirection. This makes it easy to modify
installed applications with service packs or application updates. In this situation,
deleting the old DLL and installing a new version is not enough; this will simply
stop the application from running.

Microsoft Windows Installer

Visual Studio .NET provides special project templates that allow you to build
installers for different types of applications.
After you have chosen a project, you can customize the installation procedure by
modifying the registry, adding file types, adding shortcuts and any arbitrary files
(including documentation), and specifying conditions that must exist on the target
 Chapter 2: Practices for Successful Upgrades 55

computer before the installation will continue. In addition, you can add your own
custom installation actions and application specific dialog boxes to the installation
process.
The setup projects offered by Visual Studio .NET are usually built to create Windows
Installer files (.msi) that can be stored and distributed on a CD, on a Web site, or on a
shared network directory for installation across a network.
Visual Studio .NET provides the following deployment projects for installing differ-
ent types of applications:
● Setup project. This is a generic Windows application setup project that you can
add arbitrary files and actions to.
● Web Setup project. This kind of project is intended for installing Web applica-
tions and can automatically handle issues with registration and configuration.
● Merge Module project. This type of project is used for deploying shared compo-
nents by incorporating them into other installation projects.
● Setup Wizard. This is not a type of project, but a wizard that helps you build an
initial setup project from existing Visual Studio .NET application projects. These
projects can be customized later.
● Cab project. A Cab project allows you to assemble a collection of files and project
outputs for compression and for copying onto other computers. This type of
project is commonly used for packaging ActiveX controls.

Advancing an Application
After testing is complete, you should have a working application that is functionally
equivalent to your original Visual Basic 6.0 application. In many cases, the reason for
upgrading an application in the first place was to add new features to it. After you
have functional equivalence, you can begin application advancement to achieve the
results you envisioned. All new development will be done in Visual Basic .NET.
Application advancement is the improvement of the upgraded application beyond
the specifications of the original application. It often includes adding features that
are easier to implement in Visual Basic .NET than they were in earlier versions of
Visual Basic. For some features, such as threading, it may be the first time it is
possible to implement the feature in your application.
For detailed information about application advancement, see Chapters 17, “Intro-
duction to Application Advancement,” Chapter 18, “Advancements for Common
Scenarios,” Chapter 19, “Advancements for Common Web Scenarios,” and Chapter
20, “Common Technology Scenario Advancements.”
56 Upgrading Visual Basic 6.0 Applications

Managing an Upgrade Project

In terms of management, upgrade projects differ from standard development
projects in ways that are important to understand. This section discusses many of
the best practices and techniques to ensure that your upgrade project goes as
smoothly as possible.
The practices and techniques described here come from experience with many
Visual Basic upgrade projects. Microsoft and their partners have learned some
valuable information by upgrading millions of lines of Visual Basic 6.0 code to
Visual Basic .NET. This section shares some of those lessons with you to give
you the benefit of this experience.

Change Management
You will find that source management issues are more complicated during an
upgrade project than they are during typical application development projects. If
you do not have a source control system you should consider purchasing one; it will
save a lot of headaches caused by multiple programmers working on the same set of
files and overwriting each other’s work.

Using Source Control

A source control system is a software program that manages the work done by a
group of two or more developers who are working on a single set of source files. It
prevents the developers from modifying the same source files at the same time only
to lose valuable work as a result.
Different source control systems can have widely varying features for supporting
different types of files and different numbers of users. However, most source control
systems will have the following basic set of features:
● Storage of the entire source tree and related files. The source control system
includes a directory structure that contains all the source code and related files
for your application. This directory structure is referred to as a source tree. The
source tree is centrally managed by the source control system and is stored on a
server that is accessible by all developers.
● Exclusive access to files. Users can check out a file for temporary exclusive write
access. While checked out a file can only be modified by the user that checked it
out. Other users cannot check out the file or modify it during this time; they can
continue to read the file, but they only see the version of the file that existed
before it was checked out. After the user has finished modifying the file they can
check it back in and the changes are available to all other users. Another user can
then check out the file to work on. This way a developer is much less likely to
overwrite changes made by another developer.
 Chapter 2: Practices for Successful Upgrades 57

● Version history. As files are changed and the application progresses, source
control systems keep histories of the files that allow you to see how the applica-
tion looked at any point in time. This feature makes source control systems useful
even for single developers who need to keep track of previous versions of their
source code. For example, in most systems you can label versions of source files
so that you can easily extract a version of the source control that matches the
version that a particular customer has. With the exact version you can more easily
reproduce bugs.
● Source branching. Most source control systems allow you to have multiple
branches in your source tree where different teams of programmers are working
on different versions of the application simultaneously. Usually, at some point,
the different versions are merged into a single branch again. For example, in the
case of the customer who has a bug in their version of the application, you may
need to replace the application with a more current version. However if you have
continued to develop the application and it is not yet stable or you do not want to
give them new features that are in the current version, you can branch the code at
the version of the source that they have and fix the bug within their version. The
resolution of this bug can then be merged back into the main source branch later.
Some of the advantages of using a source control system are:
● You minimize lost work due to programmers overwriting each other’s work.

● You always know who is working on each source file and can coordinate multiple
changes to those files.
● You simplify the coordination of multiple programmers working on the same
application.
● You always have access to any previous version of your application.

● You have a controlled way to release a single programmer’s source file changes to
the rest of the development team.

Dangers of Multiple Check-Outs and File Merging

Managers of source control systems sometimes allow developers to check out the
same source files at the same time. When this happens you might find that two
developers have made independent changes to the same file. Many source control
systems allow this and provide tools to help merge those changes. Usually the
developers will coordinate with one another to minimize the impact by modifying
different parts of the source files.
When development work begins on the code generated by the upgrade wizard,
many of the source files for the application will not compile. Also, some of these files
will have complex interdependencies that prevent them from compiling until the
files that they depend on are compiled first.
58 Upgrading Visual Basic 6.0 Applications

It is tempting to solve this problem by allowing multiple check-outs of source files.

If you do, developers can work on the source files independently to resolve issues so
that dependent files can compile. This should be avoided in Visual Basic upgrade
projects, especially at the beginning when the project is first being compiled. In most
cases two developers working on the same file will have to make the same set of
changes to that file so that it can compile. This results in duplicated work and
sometimes a more difficult merge because the same lines of code have been changed
by more than one developer.

Source Branches
As previously discussed, many source control systems will allow you to create
independent branches in your source code where there are multiple versions of your
application being developed independently. Depending on the source management
policies of your office, you will probably use several different source branches
during the upgrade project. The following source branches may be included:
● Original source branch. The original source code will usually have its own
branch. If there is any chance that you will need to continue development of the
original Visual Basic 6.0 application, you should leave the original version of the
application in its own branch and create a new branch for the upgrade.
● Code preparation branch. As previously discussed, code preparation involves
modifying the original Visual Basic 6.0 source code to prepare it for use with the
upgrade wizard. Although the application remains a valid Visual Basic 6.0
application, the modifications involve changes to the source code that can intro-
duce bugs.
Some development centers have strict restrictions about changes made to the
source code and rules about how those changes are tested and even checked in.
For example, it is common for many companies to insist on an initial set of tests
before files are even checked in; these are referred to as check-in tests.
In these cases it is useful to create a source branch especially for the code prepara-
tion. In this way all of the changes that you make to the original application are
kept separate from the main branch of development and the original application
can continue to evolve.
● Green code and functional equivalence branch. After the code is prepared
you will pass it through the upgrade wizard and a new Visual Studio .NET
solution will be created. As previously explained, this new solution is referred to
as green code.
The green code is a brand new version of your application, independent of the
source code branches that contain the original and the prepared code source trees.
When you are happy with the output of the upgrade wizard, all further develop-
ment will apply to the green code.
 Chapter 2: Practices for Successful Upgrades 59

Instead of using a new branch from the original application, it is common to create
a brand new source tree. This new source tree will be used as the basis for the next
step in the upgrade process: compilation.
In fact, after the upgrade wizard has generated the source tree, the green code is
typically used for the remaining steps of the upgrade. The first step is to achieve
functional equivalence with the original Visual Basic 6.0 application and the second
step is application advancement that involves adding new features and improving
existing functionality. All of this work is serial and can be performed on the same
source tree just as with any other development process.
At times, you may want to create reports of the changes that were made to the green
code. As previously mentioned, your source control systems provide a mechanism
to generate a copy of the original green code files and a copy of the source code at
any point. With these reports, you can determine the exact changes made to the
source code by comparing the files of the green code versions to the functionally
equivalent version.

Managing the Project after Using the Upgrade Wizard

After you use the Visual Basic Upgrade Wizard, your application will have a large
number of source code files that do not compile. It can be a challenge to determine
the best way to manage the compilation of the files, especially if you have a large,
complex project. Certain goals will be obvious but how to reach these goals may not
be. The following tips can be helpful in managing the compilation of source code
files after you use the upgrade wizard:
● Make sure that all bottlenecks are identified early. Avoid having one developer
work on a single file that the rest of the team must wait for before they can do
their work.
● Start work with the files that have the fewest dependencies on other files but that
also have the greatest impact on the application.
● Make sure that the same problems are not being fixed multiple times by different
developers.
● Minimize the number of bugs that are introduced by developers making unneces-
sary changes to the code.
● Minimize repetitive and laborious tasks that can be avoided.

● Minimize the effort that is required to achieve functional equivalence for your
application.

Handling Non-Compiling Files with Complex Dependencies

If you take a random file from your green code and attempt to compile it you will
find references to objects in many other files that are not yet compiling. You will find
that you cannot complete the file you are working on until the other files that it
60 Upgrading Visual Basic 6.0 Applications

references are also compiling. If you have multiple developers working on separate
files you will find that they all will have dependencies on common files and they
will have to wait while one person fixes the file they all need.
The obvious way to minimize occurrences of this scenario is to determine the files
that have the fewest number of dependencies on other files and to start correcting
those. Another characteristic to consider is how many other files depend on the files
that you start working with. The files that are most important to start with are those
that depend on no other files but have many dependants. This way when the file
does compile you enable the compilation of as many other files as possible at the
same time.
The assessment tool provides a lot of valuable information and even suggests the
order that files should be handled during compilation. For more information about
the assessment tool, see Chapter 5, “The Visual Basic Upgrade Process.”

Prioritizing File Compilation

Obviously, before your application reaches functional equivalence all of the files
must compile. To keep your developers productive, make it a priority to fix files so
that they can compile, even at the expense of temporarily losing some functionality.
Needless to say, the interdependence between files can make compiling those with
dependencies on other files a frustrating task.
You will often find that to proceed with work on some files, certain other files must
be able to compile first. Occasionally, you will also determine that some groups of
files must be worked on simultaneously. This might be because of co-dependencies,
where files depend on each other, or where you simply need to start making
progress on some files even though the files they are dependent on are not yet ready.
In these cases, an iterative approach is typically the best way to manage compilation
work on several files at the same time.
The first step is to address all of the local compilation issues in the file. These are
issues that are caused by, as well as fixed by modifications to the file itself. For
example, these can be syntax issues, missing functionality issues, or uses of default
properties. Issues that are caused by problems in an external file can be skipped
during this step.
Each developer should fix all of the issues that they find in their respective files and
then check in the modified files for other developers to use.
After all of the local compilation issues have been addressed, the developers can
address the global or external compilation issues. These are issues that are caused by
a problem in a different file that is being edited by a different developer. Global
compilation issues are problems with the code that can only be resolved by editing
files that are external to the file being compiled. Many of these issues will be re-
solved automatically by the developers that solve local compilation issues in their
own files. The rest of these issues will have to be specifically addressed.
 Chapter 2: Practices for Successful Upgrades 61

As developers resolve local issues and check in their files, other developers should
perform additional searches for local issues in their own files. Often a change in one
file will fix the problem in another file, effectively converting what was once a global
issue into a local issue.
With this approach, you will gradually move your files into a state where they will
compile successfully. This process will be easier if the files have as few external
dependencies as possible

Shortcuts for Getting Files to Compile

A common strategy for getting files to compile as soon as possible is to comment out
functionality that has not yet been upgraded completely. Commenting out code to
make it compile is effectively postponing the resolution of problems until later. This
can be good and bad.
If the problem you are avoiding is a superficial fix to the GUI, or involves a piece of
isolated functionality in the behavior of the file, or application, it may be okay to
comment out. However, if it is a fundamental piece of functionality whose absence is
difficult to notice during routine testing, such as logging messages, inserting or
modifying data in a database, or including certain data financial calculations, it may
be costly to comment out because the missing functionality might go unnoticed until
much later when it will be more costly to fix.
If you do decide to comment out functionality to quickly get files to compile, it is
important that you do not forget about it, and thereby introduce new bugs into the
application. You should record what you comment out, either in a task list in Visual
Studio .NET or by having the application print a message each time that area of the
code is executed. Record it in a way that the commented-out functionality will be
noticed and can be addressed later.

Divide and Conquer

As with managing most big tasks, a good approach is the classic divide-and-conquer
strategy. There are two ways to apply this concept to your upgrade project. The first
way is to delegate the work based on projects or files. Assign individual project or
source code files to your developers and have them focus on getting them to compile
first. As previously mentioned, the assessment tool (available for download from the
community site for this guide, as discussed in the “Feedback and Support” section
of the Preface) will help you determine the optimal order for working on the files.
The goal here should be to get all of the files to compile. Whether you do this with
projects, groups of files, or individual files really depends on the sizes of the files.
62 Upgrading Visual Basic 6.0 Applications

After all of the files are able to compile, there are usually remaining issues that
concern missing functionality that need to be resolved. Either code was commented
out, or green code was marked as code that potentially behaves differently. These
issues usually result in a list of tasks in the Visual Studio .NET Tasks window and a
list of EWIs and other code that was commented out while making the files compile.
You can continue to delegate work based on project or source code files. Alterna-
tively, it may now make sense to delegate work based on EWIs or tasks. You can
assign specific EWIs to developers or you can assign them selected lists of tasks. You
may want to do this when some issues need specialized knowledge and it makes
sense to assign them to appropriately capable developers. The advantage of this is
that it allows your developers to specialize in certain aspects of Visual Basic .NET to
speed up progress on the project.
The following common tasks can be assigned to developers instead of assigning
them files to compile:
● Typing variables that have no type or are typed as objects. The upgrade wizard
that ships with Visual Studio .NET does not attempt to induce the type for
variables that are not typed explicitly or are assigned some generic type. (The
ArtinSoft Visual Basic Upgrade Wizard Companion will do this. For more infor-
mation about the upgrade companion, see Chapter 5, “The Visual Basic Upgrade
Process.”) This leads to variables that have inappropriate types and the inability
to recognize the use of default properties. An important task that needs to be
done is to find variables in each file whose types have been upgraded to Object
and assign them a more suitable type.
● Manually fixing code that did not convert correctly. Typically, functionality that
was not upgraded correctly by the upgrade wizard in one file also appears in
other files in your application. An API such as the printing API, and the use of the
Windows Forms collection that has no direct equivalent in Visual Basic .NET, are
examples of functionality that can not be upgraded and will appear in multiple
files in your application. To fix these problems, you can assign developers specific
APIs and have them review and upgrade the uses of those API’s in your applica-
tion.
● Testing ActiveX/OCX components. Many ActiveX and OCX components will
work with the wrappers that are generated by the upgrade wizard however,
some will not. It is useful to know the ones that will not work at the outset of
your upgrade project. Before you start your upgrade project, determine the
Active X and OCX components that will not work in the .NET environment. You
should do this outside the application’s context to simplify the fixing of bugs in
the component. This ensures that any problems are a result of incompatibility
between the component and the wrapper, or between the component and the
.NET Framework, and not because of issues within the upgraded application.
 Chapter 2: Practices for Successful Upgrades 63

● Removing dead code, redundant declares, structures, and consts. It is common

when using functionality from DLLs to copy and paste code that contains all the
necessary Declare statements from Web pages or help files and to include a lot of
code that is not required because you do not need the functionality they provide
access to. This leads to a lot of redundant external references that can clutter up
your code and make the upgrade more difficult. These statements can be cleaned
out of your green code at any point, if they were not removed during code
preparation.

Upgrade Project Complications

Even well prepared code may have complications that appear during the upgrade
process. This section investigates common complications and how to address them
in your upgrade projects.

Managing a Continuously Developing Visual Basic 6.0 Application

If your company has active technical support and customer service departments
along with a large user base for you application, you may find that your application
is under continuous development. Typically, such development cannot be put on
hold during an upgrade. The primary solution to this problem is to create a source
branch in your source control system (or simply create a copy of the source code)
and to upgrade a version of the application from some specific point in time when
the application is functionally stable.
After the application is upgraded, you will have a Visual Basic .NET application that
is functionally equivalent to an older version of your Visual Basic 6.0 application. If
all of the changes that were made to the original application up to that point are
recorded in sufficient detail, you should be able to quickly add the new functionality
to the .NET application to bring it up to date.
Practically speaking, if this scenario applies to you, the process of moving your user
base from the old version of the application to the new version of the application
will be a major undertaking in itself and will overshadow any minor bugs reported
while the application was being upgraded.

Dealing with Strict Compilation Requirements on Checked-In Source Code

This section only applies to you if you are already using a source control system and
your office policies restrict changes that can be made to your application’s source
code. Policies like this might require check-in tests to be performed before you check
in code or they may require expensive quality assurance cycles after you check it in.
If this is the case for you, you can create an independent branch in your source
control system that you can use to perform the code preparation. Any changes you
make to your source code are independent from the main branch, and you are free to
check in the source code as you want.
64 Upgrading Visual Basic 6.0 Applications

Handling Multiple Visual Basic 6.0 Projects with Shared Files

A problem can occur with files that are shared between projects because the upgrade
wizard will not recognize these files as shared. It will upgrade them repeatedly, once
for each project that uses them. This is easy to spot because the upgraded files will
have the same names and namespaces in Visual Basic .NET; however, they will not
show up until compilation.
You can create a new Visual Studio .NET solution to hold all the projects that you
will need to manually review. In it, you can see the files that were shared and are
now repeated in different projects to determine which project the files really belong
to. With this information, you can fix the references accordingly.
Care should be taken when you do this because there are likely minor differences in
the shared files because of the context differences in the way they were upgraded.

Handling Circular Dependencies in Visual Basic 6.0 Projects

Circular dependencies are a sign of bad programming practice, but they do exist.
They are caused by groups of two or more projects being co-dependent. For ex-
ample, two projects are co-dependent if each project had a reference to a DLL in the
other.
If this happens, the upgraded projects will suffer from the same co-dependence. To
fix this issue you will have to locate the sources of the dependencies and try to
resolve them so that they are no longer circular. You can usually do this by moving
code from one project to another. It is preferable to make these changes during the
code preparation phase of the upgrade because it will lead to better source code in
the upgraded application.

Managing a Partial Upgrade

If you have decided to perform a partial upgrade (meaning that some of your
application will remain in Visual Basic 6.0 while you upgrade the rest of it), you
need to decide how to handle the source code management of this process. Obvi-
ously, the issue is that some components of the application are being removed and
replaced by new .NET components while others are not.
Chapter 14, “Interop Between Visual Basic 6.0 and Visual Basic .NET,” examines in
detail interoperability between Visual Basic 6.0 and Visual Basic .NET. Refer to this
chapter to familiarize yourself with the concepts and their limitations before under-
taking a partial upgrade.
In terms of the management of source code in a partial upgrade, you have two
approaches to choose from; both will probably apply.
In the first approach, you replace a component, such as a COM object or DLL, with a
.NET DLL. If you can manage to do this without changing the code that uses the
 Chapter 2: Practices for Successful Upgrades 65

DLL, you will have a much easier process. In this case you simply create a new .NET
project that will eventually replace your old DLL. Whether or not you are using a
source control system, it is a simple process because you create the new DLL inde-
pendently of the current DLL and start using the new DLL when it is ready.
The second approach involves replacing the user of a component, such as a COM
object or DLL, with a .NET equivalent. The development of the client is independent
of the original client and the new client is used when it is ready. If you can avoid
changing the shared component, the process is much easier. If the component must
be changed, try to make the change to the original project before starting the up-
grade instead of during code preparation.

Using Historical Information

Every application is different. It is impossible to know how many and what kind of
upgrade issues your application will have. To provide some guidance for you, this
section provides a few general statistics that are based on a large number of success-
ful upgrades that have already been performed. Please note that all of the statistics
in this section are from projects that were first prepared in Visual Basic 6.0 for the
upgrade to Visual Basic .NET. If you do not prepare your application in Visual Basic
6.0 first, you can expect your actual numbers to be much higher. However, do not be
afraid of a large number of issues being reported by the upgrade wizard. Most of
them will be very simple to resolve after you understand why they have occurred
and how to correct them.
The five most common upgrade issues generate 88 percent of the total issues. Table
2.1 lists them with the percentage that each generally occurs:
Table 2.1: Top Five Upgrade Issues
Issue Occurrence
Could not resolve default property of object “<objectname>” 52%
Property/method was not upgraded 13%
Property/method/event is upgraded but has a different behavior 12%
COM expression not supported 7%
Use of Null/IsNull() detected 4%

These are all micro issues. Micro issues are commonly-occurring, easy-to-fix prob-
lems. From these projects, 41 percent of the issues occur in the design of forms, 59
percent of the issues occur in modules, classes, code-behind-forms, and other project
items. On average, modules, classes and code-behind-forms have one upgrade issue
for every 106 lines of code; forms have one upgrade issue for every five controls.
66 Upgrading Visual Basic 6.0 Applications

Best Practices for Performing Your Upgrade

The following recommendations can help you maintain better control over the
execution of your project and will also help you manage potential risks associated
with the upgrade:
● Software applications are usually living assets in their companies, so freezing the
code development on an application is hard to accomplish. Do your best to
perform the upgrade during a period when you can restrict the coding of that
application to solving major bugs. This allows you to accelerate the upgrade
process, reduce the probability of having to make changes to the original applica-
tion as well as the upgraded one, and simplify the source code control during the
upgrade. If it is not possible to halt development, you must upgrade a frozen
copy of the source code and record changes and bug fixes that must be applied to
the application during or after upgrade.
● Try to assemble an upgrade team composed of developers and testers who know
the Visual Basic 6.0 application, and developers and testers who have experience
with the .NET Framework. This combination of team members will handle
technical aspects of the upgrade, while team members who have the required
business skills but not necessarily the technical knowledge can ramp up to speed.
● Make your upgrade project a priority and ensure that your developers are dedi-
cated to it. This support helps your team focus and begin working on the new
code base.
● Understand and categorize the upgrade issues that need manual intervention.
While many of them can be fixed quickly and mechanically, others require closer
attention. Assess your team’s abilities to fix the different categories of issues,
including their potential affect on the project schedule.
● Share upgrade knowledge with your entire team. A single solution may apply to
all occurrences of several issues found during the upgrade. Keep your developers
up-to-date with the solutions that are being implemented by others. You can do
this with knowledge base software, documents that are posted to your intranet,
regular team meetings, and any other knowledge dissemination mechanism that
your company uses.
● Make achieving functional equivalence a goal. When your Visual Basic .NET
application is functionally equivalent to the Visual Basic 6.0, you have a solid
basis for adding new functionality. Even if the upgraded application does not
entirely follow the recommended practices for the .NET Framework, or it has not
been fully optimized, you have the opportunity to validate its functionality. Then,
in a controlled way, you can begin improving the application with fine-tuning,
security implementation, and remote deployment, in addition to many of the
other features that are offered by the .NET Framework.
 Chapter 2: Practices for Successful Upgrades 67

● When solving a problem during the upgrade, keep in mind that you want to
preserve the functionality, not the code. Sometimes it is better to replace an entire
piece of code with functionality that is provided by the new platform than to try
to re-implement the old features in the new platform just to keep things exactly
as they were in the original application.
● Divide the testing phases into partial testing and full testing. Partial testing can
be understood as code and unit testing; it is focused on isolatable pieces of the
application such as components, classes, a particular method, and so on. Full
testing — also referred to as system testing — comprises the testing of the func-
tionality of individual components, the functionality of the entire application,
and the application’s integration with other applications. Partial testing will find
errors before you integrate the entire system. It is not unusual to find bugs in the
upgraded application that also exist in the original application but that have not
yet been detected. Differences in the execution of the applications in the two
environments can identify such errors. Resolving these bugs may be simpler
when they are found during unit (localized) testing instead of during full system
testing.
● Test cases are a great measurement tool for quantifying the progress of the up-
grade process. They also confirm when the application reaches functional equiva-
lence. As with any software project, test cases help to maintain a high level of
quality in your application.
● Dedicate resources to testing. If you do not have dedicated testers, assign one set
of developers to perform the upgrade and a different set of developers to test the
upgraded code. This will improve the effectiveness of bug detection. Assign team
members who know the business perhaps better than they know the code to
testing.

Avoiding a Common Pitfalls

During the first phases of the upgrade, resist the temptation to redesign the applica-
tion. While preparing the code for the upgrade it is easy to find ways to improve the
application. If you start tinkering with the code at this stage, the upgrade process
can easily spin out of control, causing you to over extend your schedule and budget.
During the stages of compilation and achieving functional equivalence you should
focus only on these tasks — not on redesign. The algorithms worked before so stick
with them for now, but all the while do keep track of areas you can improve after the
application has reached functional equivalence.
Also, if the code generated by the upgrade wizard works, do not try to improve it
just because there is a .NET alternative for it. Leave these tasks for the application
advancement stage.
Remember that the primary goal of your upgrade project should be to achieve
functional equivalence. Only when functional equivalence is reached should you
begin the tasks for improving and optimizing the application.
68 Upgrading Visual Basic 6.0 Applications

Summary
Deciding whether reaching functional equivalence is sufficient or if you need to add
new features to an application is an important decision that you should consider
before you begin an upgrade project. Although you can start by first achieving
functional equivalence before adding new features, you should plan ahead for
future advancements so that any necessary hooks can be included during the up-
grade to facilitate future development work.
Understanding the different upgrade strategies and when each should be applied is
important so that you can make decisions, plan the upgrade, and the associated
estimate costs and effort. Should you upgrade your entire application, or only parts
of it (leaving parts in Visual Basic 6.0, which will require the use of interoperability
techniques)? Should you perform the upgrade all at once, or do it stages one compo-
nent at a time? These are questions you will have to answer before you can even
begin upgrading.
Finally, a successful and efficient upgrade project relies on a methodical approach
with clearly defined stages. The process outlined in this chapter provides you with
the knowledge you need to prepare and to carry out realistic upgrade project plans.

More Information
For more information about Visual Studio, see the Microsoft Visual Studio
Developer Center on MSDN:
http://msdn.microsoft.com/vstudio/.
3
Assessment and Analysis

Introduction
Assessment and analysis usually means two things: determining how best to up-
grade your applications to the Microsoft .NET Framework and how much it will
cost to do this. This chapter discusses the best ways to gather this information.
The “Evaluating Upgrade Objectives” section discusses many of the common
expectations that come with an upgrade to Microsoft Visual Basic .NET and dis-
cusses the realities behind those expectations.
The “Gathering Data” section provides information about what you should have
ready to help you make important decisions for the upgrade process and how best
to gather that information.
The “Application Analysis” section examines the Visual Basic 6.0 Upgrade Assess-
ment Tool (included with this guide) and how to use it to get statistical, structural,
and functional information from your applications. You will also learn how to use
this information to help you make decisions about the best way to upgrade your
applications.
The “Estimating Effort and Cost” section explains how to estimate the time and cost
of your upgrade project.
Each section describes how to collect the information you need and the value of this
information to the project. You will see how best to use the information to reduce
costs and risks and to increase your return on investment (ROI).
To best determine the strategy and cost for upgrading your application, you need to
ensure your scope and plan your project appropriately, and then test the upgraded
application fully after it is a .NET Framework application. You have to be aware of
70 Upgrading Visual Basic 6.0 Applications

all the assumptions you are making and the expectations you have and to ensure
that they are all correct. This chapter helps you learn how to do so.

Project Scope and Priorities

Probably the most important information that you can get from analyzing your
application, and the information that has potentially the greatest effect on the effort
and cost of the upgrade project, is the information that is needed to define the scope
of the project. When you are defining the scope or your project, the considerations in
this section will be helpful.

Identifying Components That Must Be Upgraded

Many factors will contribute to deciding which parts of your application must be
upgraded to .NET. For example, it may be that you want to consolidate your server-
side technology, but you may decide that upgrading the client is secondary. Alterna-
tively, you may want to improve the integration with the Internet or Web services or
add this functionality. In these scenarios, it may be necessary to upgrade only those
portions that will interact directly with the improved or newly added functionality.
These requirements will mean that certain components of your application must be
upgraded to Visual Basic .NET. Through normal dependencies, other components
will also need to be upgraded. However, because of the interoperability possibilities
between Visual Basic 6.0 and Visual Basic .NET, you will not need to upgrade all
your code. For more information about interoperability, see Chapter 14, “Interop
Between Visual Basic 6.0 and Visual Basic .NET.” For more information about
upgrade strategies, see Chapter 1, “Introduction.”
Also, the parts of your application that you upgrade may be limited by available
resources, such as how many developers are available, how much time you have
to perform the upgrade, and how much effort would be needed to complete the
upgrade.
Later in this chapter you will learn how to track the dependencies between compo-
nents of your applications. You will also learn how to measure the size of your
applications and estimate the effort required to upgrade the individual components.
This information will prove valuable in determine the scope of your upgrade
project.

Identifying Obsolete Components

When assessing your application for upgrade, you will find areas of functionality
that are no longer used. This is especially true in earlier applications that were
developed by a series of development teams over several years. Often, features are
added to applications and then later those same features are no longer used because
the business changes focus or operating procedures. Frequently, these features can
be removed before the upgrade, potentially saving significant amounts of work.
 Chapter 3: Assessment and Analysis 71

Typically, the older a feature is, the more likely it is that it depends on some behav-
ior of an earlier version of Visual Basic that is no longer supported in Visual Basic
.NET — a behavior that would be difficult to upgrade to Visual Basic .NET.
There are several analysis techniques that you can use to determine the features that
are no longer used and can be left out of the upgrade. Use case analysis and input/
output analysis are two such techniques that are discussed later in this chapter.

Managing Upgrade Expectations

Managing expectations is important in any development project. It is even more
important in an upgrade project because people have different ideas of what an
upgrade is and different reasons for performing the upgrade. Later in this chapter,
you will find a list that includes many of the common expectations that people have
for an upgrade project and the objectives that they believe the upgrade is attempting
to reach. This list helps you manage the expectations of various people interested in
your project and prevent unwelcome surprises.

Planning
To create an effective project plan, you have to know exactly what has to be done,
who is available to do it, and how long it will take. Some of this was described in the
“Project Scope and Priorities” section earlier in this chapter. The following sections
discuss some other considerations that you should keep in mind during planning
and that can be clarified with careful application of the Visual Basic 6.0 Upgrade
Assessment Tool (hereafter referred to as the “assessment tool”).

Identifying Components Requiring Significant Upgrade Effort

Some components can be upgraded to .NET more easily than others. For example,
you may not have access to source code for third-party components. Other compo-
nents may rely on features that require a lot of work to be upgraded; for example,
components that make extensive use of Data Access Objects (DAO) or Remote Data
Objects (RDO) for data access. These components should be given special attention
during the upgrade planning stages because they correspond to the riskier areas of
the upgrade.
Later in this chapter, you will find detailed information about the assessment tool
(included with this guide) and how to use it to identify the components that will not
upgrade easily to Visual Basic .NET.

Quantifying the Amount of Code to Upgrade

The number of lines of real code in your application, not counting comments or
blank lines, is a useful indication of the complexity of an application. In fact, the
number of lines of code is not used directly to estimate effort; instead, it is used as
72 Upgrading Visual Basic 6.0 Applications

a weight that affects other elements of the estimation. For more information, see
“Estimating Time and Cost” later in this chapter.
For example, the number of lines of code affects the amount of time required to
create an inventory of the application, define the order of the upgrade, review the
upgrade report generated by the first run of the Visual Basic Upgrade Wizard, and
so on.
The assessment tool reports how many lines of code there is in the application and
in each of the files and components that comprise the application.

Determining Upgrade Order

Because of the complex interdependencies that usually exist between components
and files in an application, it is normal to wonder which files, components, and
modules you should approach first in a large upgrade project. Physically, the files
that make up your application contain dependencies that force you to approach the
upgrade of the files in a predetermined order, unless you are prepared to redesign
some of your application. However, logically and even strategically, it makes more
sense to upgrade your applications on a component-by-component basis, indepen-
dent of the relationships between the files.
Your own business and technical needs will determine the order in which to up-
grade the individual components of your application. When there is doubt, the
assessment tool can shed light on current physical dependencies between compo-
nents to help support your decisions at the component level. It is common to find
dependencies between components that were unexpected and highlight weaknesses
in the design or implementation of an application. After you choose the order in
which to upgrade the components, and depending on how many files make up the
component, you have to decide the order in which to upgrade individual files. The
recommended approach is to start with the files that depend on the fewest number
of other files, and then work your way through the dependency hierarchy. The
assessment tool helps a great deal with this because it shows exactly what depen-
dencies each file has and even suggests an upgrade order based on this information.

Assessing the Necessary Technical Expertise

When planning what needs to be done and in what order, you must also decide who
will be responsible for each of the tasks that you identify. The assessment tool
produces a report in the MainReport.xls file to assist with making these kinds of
decisions. The Config – Resources tab of this file provides a list of recommended
resource categories with a description and cost-per-hour for each category. Although
default costs for each category are provided, these values can be modified to fit the
actual costs for your company.
 Chapter 3: Assessment and Analysis 73

The MainReport.xls file also provides a fairly complete set of information about the
kinds of tasks that need to be completed to upgrade your project. Furthermore, it
hints at the resource categories needed to complete those tasks.
For example, each error, warning, or issue (EWI) that is found by the upgrade
wizard has an associated suggested resource, such as developer or architect, that
implies a minimum level of experience for the individual that is responsible for
resolving that EWI. These are default suggestions provided by the assessment tool,
but these can be adjusted in the Config – EWI tab if you disagree with any of the
suggestions.
Also, all the different features of Visual Basic 6.0 code that require manual upgrad-
ing have associated with them suggested resources in the Config – General tab of
the MainReport.xls. These values can also be adjusted, which allows you to select
your own resource if you disagree with the suggestion.
The suggestions made for the type of resource required to deal with the various
upgrade tasks are based on experience with numerous Visual Basic 6.0 upgrade
tasks. However, your situations may vary depending on the resources available in
your company. The configurability of the reports allows you to adjust them to suit
your environment.

Estimating Time and Cost

These two estimates are usually the most important and traditionally the most
difficult to determine. Among other things, they depend on the available resources,
developer skills, experience, and knowledge, and quality and size of the application.
The MainReport.xls file produced by the assessment tool provides assistance with
cost and effort estimates by providing suggestions of the types of resources needed
for various upgrade tasks, the cost for each type of resource, and the length of time
that resource will need to perform the task.
The MainReport.xls file contains several tabs the report the estimated cost and effort
for upgrade tasks, as listed here:
● Effort – Total: This tab provides a report of the complete estimated effort and
cost.
● Effort – By Resource Type: This tab summarizes the effort estimate for each
resource category.
● Effort – By Task: This tab summarizes the effort estimate for each upgrade task.

● Effort – EWI: This tab summarizes the effort estimate for each EWI.

Each of these tabs is discussed in more detail in the “Estimating Effort and Cost”
section later in this chapter.
The estimates shown in these tabs are based on configurable values found in other
tabs. As mentioned in the previous section (“Assessing the Necessary Technical
74 Upgrading Visual Basic 6.0 Applications

Expertise”), you can use the Config – Resources tab to adjust the cost for each type
of resource. The values you supply will automatically be used in the effort reports.
The Config – EWI and Config – General tabs suggest the type of resource and the
length of time required to perform various upgrade tasks. These values can also be
modified to suit your needs, and any changes you make will be reflected in the
effort reports that depend on them. Thus, the task of estimating cost and effort for
your upgrade project is simplified because you need only specify modifications in
the configuration tabs and all effort reports are automatically adjusted to reflect your
modifications.
The configurability of the various estimates in the MainReport.xls file will help your
organization improve their accuracy over time. The more upgrade projects your
developers participate in, the more information you gather about the costs and effort
required to handle different aspects of upgrading. This information can then be used
to adjust cost and effort estimates in the assessment tool reports in future projects.

Defining Priorities
Another important goal of the type of application analysis is defining upgrade
project priorities. This is important because it helps focus effort and direct decisions.
Priorities depend on the business and technical objectives at the root of the upgrade
project, but to some degree, it also depends on the result of the analysis of the
content, the operation of the application, and on the time and budget available.
Depending on the content of the application, priorities might include risk manage-
ment by requiring a pilot project or initial testing of certain parts of the application.
One example scenario is where new business requirements include specific increases
in performance or scalability to a handle a larger user base. This requires a close
analysis of the current architecture and bottlenecks and a good understanding of the
features of Visual Basic .NET that can increase performance and scalability. Chapters
1 and 14 discuss some of these features. Prioritizing bottlenecks helps to speed the
upgrade.
Another example scenario is the addition of a new Web service interface in as little
time as possible. If interoperability is an acceptable solution, a partial upgrade may
be all that is necessary because you only need those components that provide
content to the Web service; the other components can remain in Visual Basic 6.0.
Here, prioritizing only the additional service would achieve the most efficient
solution in terms of time and cost.
One final example is a scenario where the priority is consolidation. In this case, a
partial upgrade is not an option and focus must be placed early in the project on
those components that are more difficult to upgrade because they are the potential
show-stoppers.
 Chapter 3: Assessment and Analysis 75

Evaluating Upgrade Objectives

This section examines some of the common reasons that people have for upgrading
from Visual Basic 6.0 to Visual Basic .NET and the expectations that often accom-
pany the upgrade project.
The reason should be clear for clarifying your expectations and the expectations of
your sponsors, users, and clients. You want to ensure that you are upgrading your
applications for the right reasons. You also want to make sure that the goals of your
project are achievable and that you are clear about the amount of work needed to
achieve those goals.
Most of these expectations come from one simple fact. When an application is
upgraded using the automated tools provided by Microsoft Visual Studio .NET,
most of the code used to generate the new application is based on the code that
implemented the original application. This is usually the case. However, in some
cases no code can be generated. For example, this can happen when the behavior is
not in the source code of the original application, but instead, the behavior is in a
third-party library that is no longer available.
The following sections list common objectives and the associated expectations that
lead people to believe that the objectives will be met. In each case, the reasoning
behind the expectations is discussed.

Business Objectives
Upgrade projects will have an impact on business objectives of your company. This
section addresses some of the key considerations and expectations of an upgrade
project from the perspective of business objectives.

Minimizing Organizational Disruption

An automated upgrade helps ensure that the look and feel of the original applica-
tion is maintained in Visual Basic .NET. This usually leads to the expectation that the
users do not need any training for the new application. This can sometimes be true,
but some applications fail to meet this level of equivalence for a variety of reasons.
The most common reason for this is third-party components that are not available in
.NET. In this situation, you are forced to write your own component or replace it
with one that is a little different in Visual Basic .NET. This can result in slightly
different behavior.
Any changes in performance can affect the apparent behavior of an application and
can confuse users. For example, if your .NET application performs differently, a user
may be surprised by this difference and be left wondering whether his or her trans-
action was completed properly.
76 Upgrading Visual Basic 6.0 Applications

After assessment, you may determine that certain features are no longer needed or
used. This is a good opportunity to reduce upgrade time and clean up the new
application by removing code and features that are no longer used. However, you
have to be careful when making decisions like this because other features may have
undocumented dependencies on the features you remove. Also, you may find that
some users do in fact use those features although they did not report that they use
them or they use them for reasons other than those for which they were originally
intended. For example, it is common to read information from reports that is actu-
ally secondary to the prime intent of the report simply because this report is easier
or faster to create than the one that should be used.
Other changes that can cause disruption come from the fact that any procedures you
had in place for testing and deployment will likely have to change. Because the
application is no longer based on Visual Basic 6.0, you may have to modify your
testing procedures, especially if they were automated. Also, deployment require-
ments will change, so you must also update your deployment procedures.
Finally, although the new application will contain most of the business logic from
your original application, this does not mean that your programmers have nothing
new to learn. Visual Basic .NET is a new language. It has new syntax rules, a new
API, supports a new programming methodology, and no longer supports many
common practices of Visual Basic 6.0 programmers. Upgrading your original appli-
cation is a great way for them to learn this new language, but they will need some
level of familiarity with Visual Basic .NET before the upgrade begins.

Leveraging Existing Knowledge Capital

Because the business logic encapsulated within an application represents a major
investment of time and money, throwing it all away and starting a rewrite from the
beginning is not typically the best solution. Part of the reason for choosing an
upgrade instead of a rewrite is the possibility of maintaining the most possible
investment in the original code. When an application is upgraded, very little of the
existing business logic needs to be manually rewritten in the new language. Because
much of this upgrade is automated, it can be done by developers who were not
involved in the original application development.

Reducing Risk
If the earlier application is working well and is fulfilling user and business needs, a
common expectation is that a direct upgrade to the new platform involves far less
risk — it is simply the identical business logic moved to a new platform.
Legacy code has often been facetiously defined as “code that works.” It has been
used, tested, and improved over a long period of time. If it works, there is no need
to rewrite it. Writing new code also implies creating new bugs that must be found
and fixed. Because much of the original code is automatically upgraded, you do not
 Chapter 3: Assessment and Analysis 77

need to write as much new code as you would if you rewrote the application from
the beginning. This results in less risk of introducing new bugs to the application.

Maximizing Return on Investment

Businesses only approve new projects that, directly or indirectly, will show a return
on investment. For this reason, expectations about a return on investment are im-
plicit in any upgrade project.
Traditionally, calculating the ROI is a complex task because there are so many
variables to consider. This guide can provide some pointers for calculating the ROI,
but many of the variables come from your own business practices and how the
upgraded applications are used. In simple terms, the ROI is a combination of the
amount of extra money your business makes because of the upgrade, plus the
amount of money that the upgrade saves you, minus the cost of executing the
upgrade:
ROI = Money Made + Money Saved – Cost of Upgrade.
The money you make because of the upgrade is completely dependent on the
applications that you upgrade and how they are used in your business. However, it
is often related to the new features, services, and performance that your application
offers as a direct result of the upgrade. The cost of the upgrade can be estimated
before you start the upgrade; later sections explain this in detail.
You have to analyze your applications yourself and look at how the improvements
offered by the upgrade affect the operating and maintenance costs of the applica-
tions. Because of the new technologies offered by Visual Studio .NET, there is also a
possibility that the upgraded application can reach new markets or be used by a
broader audience.
The .NET Framework and Visual Studio offer important improvements for software
development and maintenance that reduce the overall cost of building and maintain-
ing your applications. Deployment, configuration, and maintenance of the deployed
application are easier and require fewer administration resources. XML-based
configuration files, new deployment possibilities, and less invasive deployment
activities mean that deployment is less likely to cause damage to or be damaged by
installations of other software. Each of these aspects helps to reduce overall costs.
Increased performance, security, and scalability mean that your applications are
more responsive and secure. This results in less downtime, more transactions, and
more user satisfaction. All of these aspects translate into higher productivity and
more effective business processes.
Finally, because Microsoft is going to stop providing support for Visual Basic 6.0 and
all earlier versions, it is likely that soon after there will be decreasing numbers of
developers who have a good knowledge of Visual Basic 6.0. This will make finding
78 Upgrading Visual Basic 6.0 Applications

developers more difficult and maintaining your application more and more expen-
sive. Also, many businesses have made significant investments in training their
people and want to know that their skills are current. If they still need to go outside
the company for expertise, they also want to know that there is a ready pool of labor
that they can choose from. Otherwise, in time, the ROI from an upgrade will come
from the fact that it is simply more expensive to not upgrade.

Achieving Functional Equivalence

Functional equivalence is discussed in some detail in Chapter 2 and it is suggested
as the necessary primary goal of any upgrade project. In fact, functional equivalence
at a minimum is only natural to expect from a project that involves moving your
application to a new platform.
For the most part, this is a valid and an achievable goal. However, it is not without
its obstacles. Functionality that is provided by components that are not under your
control and are not available in .NET may need to be rewritten or replaced by other
third-party components or custom in-house components.
If you promise functional equivalence, make sure to confirm that it is achievable by
checking the compatibility of all third-party COM components and libraries with
.NET or, alternatively, the availability of a .NET version of those components.

Dealing with an End to Official Support for Visual Basic 6.0

As mentioned in Chapter 1, official support for Visual Basic 6.0 from Microsoft will
cease completely in March 2008. It is a major objective of many businesses to ensure
that their IT department and all their software operate on platforms and toolsets that
have manufacturer-provided support.
If you opt for a full upgrade of all your applications, instead of just a partial up-
grade as discussed in Chapter 2, you will no longer be dependent on Visual Basic
6.0. In a partial upgrade, you upgrade only certain parts of your applications and
use one of the mechanisms available for interoperability between Visual Basic 6.0
and Visual Basic .NET to get them to communicate with the parts that were not
upgraded. (For more information, see Chapter 13, “Working with the Windows
API.”) However, if you take this approach, parts of your application will obviously
still require Visual Basic 6.0. If one of your objectives is to follow Microsoft’s
planned support path, you will eventually need to move all the pieces of applica-
tions over to Visual Basic .NET.

Technical Objectives
Any upgrade project will have technical objectives behind it. This section discusses
some of the common technical objectives for performing an upgrade.
 Chapter 3: Assessment and Analysis 79

Adding New Functionality

Upgrading applications to a newer framework such as the Microsoft .NET Frame-
work enables organizations to enhance their systems with cutting edge technology.
This allows them to meet ever-expanding user and business needs such as Web
enabling, Web services, XML, ADO.NET, and ASP.NET. And because critical applica-
tions are no longer dependent on outdated and/or unsupported legacy environ-
ments, there is a clear path for longer-term support and evolution.
This is a common expectation and is often a prime reason for moving to .NET in the
first place. However, remember that these features do automatically appear. The key
word is enable; .NET enables you to take advantage of these technologies. After an
application is upgraded to .NET, you have all the capabilities and possibilities of
.NET available to you, but you still need to plan how to start taking advantage of
these technologies and then initiate a development cycle to implement the plan.

Achieving Better Performance and Scalability

Better performance and better scalability are two key improvements that .NET
provides. It is common to expect better performance and scalability from your
upgraded application.
In some cases, without any extra effort beyond upgrading your code to .NET, you
can see dramatic performance improvements in your applications. For example, the
white paper titled “Advantages of Migrating from Visual Basic 6.0 to Visual Basic
.NET” (available on MSDN) documents developers who upgraded an ASP and
Visual Basic 6.0 application to .NET. After the upgrade, they saw the throughput and
the number of users supported simultaneously increase threefold without any
modifications to the code other than what was needed to get the code running in
.NET.
Such performance improvements are not always this automatic. When you start
your upgrade project, you should consider the design of your application. For
example, you should consider how it does things in Visual Basic 6.0 and how it will
do them in Visual Basic .NET. Sometimes you may need to reconsider how things
should be done in .NET in order to improve performance and scalability. For ex-
ample, rewriting your ActiveX Data Objects (ADO) data access code to use
ADO.NET will likely show great improvements. The rest of the chapters in this
book, particularly Chapter 20, “Common Technology Scenario Advancements,” give
many pointers to where you can improve the performance and scalability of your
applications when you upgrade to Visual Basic .NET.
80 Upgrading Visual Basic 6.0 Applications

Accelerating the Development Process

A decision to rewrite code implies building the application entirely from the begin-
ning. In contrast, it is reasonable to expect that an upgrade can benefit from the fact
that much of the conversion of your original code is automated. In fact, this results
in huge improvements in productivity from upgrading, as compared to rewriting.
The main reason for this huge difference is that a rewrite involves designing, creat-
ing, testing, and debugging new algorithms, whereas an upgrade means simply
translating algorithms to the new language and ensuring that the code performs
identically to the original application.

Consolidating to a Single Framework

One of the common reasons for upgrading your applications is consolidation or
framework unification by upgrading several languages and/or frameworks to one
language and framework.
One of the biggest problems for IT organizations is supporting multiple applications
that run on different frameworks and/or are written in different programming
languages. This causes compatibility and integration issues among the applications
and can be very costly to manage. Instead, if applications run on a single frame-
work, it would be easier to manage, tune, enhance and deploy them as well as
integrate and make them interoperate. The only impediment to migrate applications
to run on single framework is the time and effort required to and the only way to
overcome this impediment is to automate the migration.
In the context of this guide, if an organization has applications based on the .NET
Framework as well as applications based on Visual Basic 6.0 then it makes sense to
upgrade the Visual Basic 6.0 applications to Visual Basic .NET. With the help of the
Visual Basic Upgrade Wizard, all the Visual Basic 6.0 applications can be made to
run on the .NET Framework using the Visual Basic .NET language at a fraction of
the time and cost that would be required to rewrite them. This will help your organi-
zation support and maintain its applications better than having to support both
Visual Basic 6.0 and the .NET Framework.

Ease of Deployment
Also of importance to IT is deploying an application across an entire organization.
Applications with sophisticated deployment schemes can be costly to install among
multiple computers. DLL versioning conflicts result in lost productivity for users
and costly trouble-shooting for IT personnel.
The .NET Framework provides application deployment options that simplify the
process of deploying applications. It also provides options to help in protecting
against version conflicts, thus ensuring that deploying a new application will not
break currently installed applications.
 Chapter 3: Assessment and Analysis 81

For more information about deployment options, see the “Upgrading Application
Setup” section in Chapter 16, “Application Completion.”

Gathering Data
As mentioned at the beginning of the chapter, our goal is to determine how best to
upgrade your applications to Visual Basic .NET and how much it will cost to do so.
With this in mind, this section examines two ways to view your applications and
extract information about them to help with your upgrade decisions.
The first way to view the application is based on how it is used. In this case, you will
have to look at the environment in which the application executes, who the users are
and how they use the application, and what features the users actually use. When
looking at your application from this perspective, remember that users in this
context can be human end users or other systems that interact with your applica-
tions. This technique for analyzing the application is especially useful if you have
reason to believe that your application contains a lot of features that were created
long ago but are no longer needed.
The second way to view the application is to analyze its content. This includes the
features that it offers, the technologies that it uses to provide those features, the code
that was written to manipulate the technologies, and the interactions between all
these pieces. Therefore, you are interested in the source code that was used to build
the application, its size, complexity, and the third-party libraries it references. Also
of interest is how the applications are structured, what subsystems the design
highlights, what dependencies the applications have on external systems, and the
mechanisms used by these subsystems and external systems to interact with each
other. The assessment tool included with this guide is a great way to start this kind
of analysis.
The following subsections examine the techniques for analyzing your application’s
usage and how the assessment tool helps catalog the elements of your application.

Assessing Application Usage

A necessary activity in developing an upgrade plan is to perform an assessment of
the application’s usage. This section examines two techniques for doing this: use
case analysis and input/output analysis.

Use Case Analysis

A very common technique for describing the requirements of software applications
is through use cases. A use case is a document that describes one particular scenario
where that system is or will be used. A complete set of use cases amounts to a set of
functional requirements for a software application and it can be used as the starting
point for more detailed functional specifications and test plans. For this discussion, a
82 Upgrading Visual Basic 6.0 Applications

set of use cases can be used to define the set of functionality that needs to be up-
graded to Visual Basic .NET. If your application already has use cases, you can use
them as a starting point. Just keep in mind that new usage scenarios may have been
added since the original use cases were created because use cases are usually created
before any application development even begins.
Examples of Use Cases
A use case usually consists of text describing a set of steps that lead to the comple-
tion of a specific task. For example, it can describe the steps a user would be ex-
pected to execute to process a check received from a client.
A typical use case contains information such as the following:
● Name. This identifies the use case.

● Description. This describes the use case.

● Pre-conditions. These indicate assumptions about what should be true before the
steps in the use case are executed.
● Steps. These are the steps that are required to execute the use case.

● Post-conditions. These indicate the conditions that should exist after successful
completion of the steps of the use case.
● Actors. This indicates who would normally execute these steps.

● Variations. These indicate alternatives to the steps. Finally, post-conditions

indicate a way to confirm that the steps were performed correctly.
The actual size of a use case can vary from a few of lines to several pages, depending
on the detail needed and the complexity of the task that is being described. At a
minimum, a use case should have a name that identifies the task in just a few words
and the steps expected to execute the use case. Names should be short but descrip-
tive; for example, “Print a document,” “Transfer between current accounts,” “Check
production level,” and “Export report to Excel.” The steps should describe the
information that must be provided to the application and the information that is
expected in return, but it should not add detail where it is not necessary.
There is a lot of documentation available for creating effective use cases, and it is all
appropriate to upgrade projects. Some simple things to remember when defining
use cases are:
● Use descriptive and precise names for your use cases. Avoid vague terms and
software-related terms. Use terminology from the business domain to which the
application belongs (such as Account, Client, Purchase Order, or Report) instead
of from the world of software and databases (such as classes, objects, SELECT, or
query).
● Address atomic tasks with each use case. Avoid creating use cases that involve
more than one goal and avoid creating use cases that address a partial process.
 Chapter 3: Assessment and Analysis 83

● Scope the use case properly. Make sure the scope of the use case is clear. This can
be done by including triggers and expected results with each use case. A trigger is
some event that usually requires or causes the initiation of the use case. Expected
results are the direct consequences of the use case.
● If you are using use cases that were created for the original application require-
ments, confirm that the use case covers a scenario that is still valid and useful.
Some older use cases may describe tasks that are no longer needed or have
changed since their original conception.
● Involve the users in the development of these use cases. In the end, it is the user’s
requirements that are reflected in the use cases, and they should be involved in
creating and verifying use cases.
Creating New Use Cases
Ideally, you should already have use cases from when the original application was
being designed. If there are no such use cases available, here are some ideas for how
to create use cases now:
● Interview current users of the application.

● Run focus groups and brainstorming sessions with stakeholders.

● Gather information through questionnaires and surveys.

● Observe users’ daily routines.

● Analyze external systems and their interaction with your applications.

Getting Information from Use Cases

After you have a representative set of use cases, you are in a position to categorize
code, components, and projects into those that implement required features and
those that are no longer needed. This helps avoid upgrading unnecessary parts of
your application, which reduces cost and effort.
Another application for the use cases is as the basis of a set of system tests that can
be used to ensure the existence and the quality of required functionality.

Inputs/Outputs Analysis
A classic way to describe computer software is by means of cataloging the full set of
data that it receives and the full set of data that it produces. This technique is a
simple but effective way of creating a formal specification for the behavior and the
usefulness of an application.
This guide does not document the implementation of the pieces of the application,
and it documents protocols, formats, the user interface, and other forms of interac-
tion with the application only in relation to the input or output being described. For
example, the user interface screen that a user interacts with to add client information
to your application is described in terms of its content instead of its layout.
84 Upgrading Visual Basic 6.0 Applications

Examples of Inputs
Inputs are anything that is entered into the application by an employee, a client, or a
user of any other kind, or an external application. Examples of inputs include:
● Raw data manually entered by a user to a data entry screen of the application,
such as customer information.
● Any documents built externally to the application and sent to the application,
such as e-mail messages, reports, lists, or raw data.
● Asynchronous messages received from other applications.

● Requests from users over the Internet or intranet.

● Software events for which the application is monitoring including timers,

amounts, or email messages.
● Hardware events for which the application is monitoring.

Examples of Outputs
Outputs are anything that the application produces, displays on the screen, prints,
sends to other applications, or stores on some storage device such as a hard disk,
floppy disks, CDs, tapes, or the network. Examples of outputs include:
● Reports that contain raw or summary information based on existing data and
usually in response to some query or as a result of a scheduled event.
● E-mail messages, faxes, or other electronically transported documents.

● Graphs, text, bar charts, graphics, sound, and other representations of data.

● Events, alerts, and other messages that are transparently logged or require
immediate attention.

Getting Information from Inputs/Outputs

With a complete set of inputs and outputs, it is often even easier to identify code
that is responsible for those inputs and outputs than it is with use cases. Again, this
is useful if you believe that you can save time by identifying components, files, or
even projects that are no longer used and therefore do not need to be upgraded.
Inputs and outputs can also help with testing because it is usually possible to create
mappings from inputs to outputs, and based on this, to build tests that can confirm
the correct functionality of the upgraded software.

Application Environment
The environments in which the applications are developed and deployed both play
an important role in helping define priorities and avenues of investigation when
issues need to be resolved.
For example, if you are not a part of the original development team, it is important
to know who is responsible for the original development, architecture, design,
 Chapter 3: Assessment and Analysis 85

implementation, and, if appropriate, product management. It is essential to have a

clear idea of the experience of the programmers who will work on the upgrade
because you may need to arrange for training or bring in someone else with more
experience in Visual Basic .NET to manage the project.
At the deployment site, you should also know who is responsible for support and
administration of the application. Here, too, training may be required because the
application technology and deployment characteristics will change.
In each case, you will need to know who makes the decisions so that you can get
direction when you need it.

Application Analysis
Determining and understanding the effort required to execute an upgrade project is
a complex task that requires the support of different tools. This process involves the
division of the entire application into smaller, more manageable pieces that can be
independently counted, understood, and estimated. As a consequence, upgrade
effort estimation is an analytical process that can be supported at different stages by
automated tools.
The original application analysis is an essential part of an upgrade project. It pro-
vides a better understanding of the application to be upgraded and produces infor-
mation necessary for planning and decision making. The assessment tool will
generate all that information in addition to information that is useful for the execu-
tion of the upgrade, such as the Recommended Upgrade Order report.
The Visual Basic 6.0 Upgrade Assessment Tool works as a measuring instrument for
an application upgrade effort. This tool analyzes the application components and
the relationships between them from an upgrade perspective, which considers
elements, constructs, and features that consume significant resources during an
upgrade project.
The main goal of the assessment tool is to analyze Visual Basic 6.0 projects and
obtain information useful for planning the upgrade to Visual Basic .NET and for
estimating the cost of the upgrade. This tool will generate a group of reports that are
used as a basis for further calculations related to task effort and cost. The assessment
tool user can specify configuration values that will override the initial estimation
inputs; in this way, the assessment tool can be adapted to specific organizations.
The assessment tool analyzes the original application using a Visual Basic 6.0 parser
that takes into account all the projects specified by the user. The obtained data is
then processed to identify usage patterns and features that are difficult to upgrade.
After all these features are classified and counted, a series of reports with detailed
and summarized data is generated.
86 Upgrading Visual Basic 6.0 Applications

It is important to take into consideration that the assessment tool considers a high
percentage of the known upgrade issues that can arise when upgrading a Visual
Basic 6.0 application with the upgrade wizard; nonetheless, there are issues that are
detected only after the full automated upgrade. The detection of these issues re-
quires complex pattern recognition rules that are available only in the upgrade
wizard. These issues can be estimated as a percentage of the rest of the issues, as is
done by the assessment tool in the Upgrade Issues report.
The following sections explain the reports produced by the assessment tool and the
aspects that are considered in the effort estimation.

Using the Assessment Tool

The assessment tool that accompanies this guide generates two Microsoft Excel®
2003 files. This first file is named MainReport.xls and contains a high level look at
the results of the assessment. When you first open the file, you will see a page like
the one illustrated in Figure 3.1.

Figure 3.1
MainReport.xls Main Page

From the page illustrated in Figure 3.2, you can access the rest of the report in an
ordered fashion.
The first thing to notice is that this report contains a link to the second report, which
is in a file named DetailedReport.xls. To allow you to keep changes that you make to
the cost and effort configuration between uses of the assessment tool, you can re-link
the main report to any other detailed report from any other assessment. All of the
application specific data in the main report is linked to the specified detailed report.
The following sections discuss the different sheets that exist in these two reports.
 Chapter 3: Assessment and Analysis 87

In general, the MainReport.xls file contains all the configuration settings, all the
estimates of cost, and summaries of the estimates of effort. The DetailedReport.xls
file contains detailed reports about the content of the application. The first page of
the DetailedReport.xls file is illustrated in Figure 3.2.

Figure 3.2
DetailedReport.xls Main Page

Current and Target Architecture

The original application architecture and project types are identified by the assess-
ment tool and analyzed to extract all referenced files and components. The depen-
dences between projects are also considered when assessing project groups.
The assessment tool can analyze the following types of Visual Basic 6.0 project types:
● Standard EXE. Standard features and functionality are considered when making
estimations that are based on average productivity values.
● Internet Information Services (IIS) application. The application is analyzed in
the standard way.
● Application that uses distributed components. The usage of distributed func-
tionality is identified and accumulated to estimate the upgrade cost of this
feature.
Visual Basic 6.0 project groups are collections of related projects that can share
resources and functionality. The assessment tool is able to process project groups
that are combinations of the preceding project types. Shared components are identi-
fied and taken into consideration when generating the Recommended Upgrade
Order report.
The upgrade path to be followed during the project depends on the relationships
between the base components, which are analyzed by the assessment tool to pro-
duce an upgrade order suggestion. Another aspect that affects the upgrade path is
88 Upgrading Visual Basic 6.0 Applications

the upgrade strategy you choose; it can be a horizontal or vertical strategy, as ex-
plained in Chapter 2, “Practices for Successful Upgrades.”
Most of the application component relationships will remain in the target applica-
tion and the application’s general architecture according to the application type
equivalencies presented in Chapter 4, “Common Application Types.” Project type
changes or re-architecture tasks are not considered in this analysis for effort estima-
tion because these are deemed to be post-upgrade tasks after the functional equiva-
lence is achieved.

Inventory to Upgrade
The first aspect to be considered in the application analysis is the inventory of
resources and components involved in the upgrade process, which includes mod-
ules, third-party components, and intrinsic components. Some of these components
are user-defined, and their implementation needs to be upgraded In addition to the
source code that uses them. For third-party and intrinsic components it is necessary
to upgrade the code that accesses the corresponding component; in this case, for
assessment purposes, it is relevant to make an inventory of the class members and
other elements that are used in the application.
The table illustrated in Figure 3.3 is from the DetailedReport.xls file and shows an
example of the Project Files Overview report that is generated by the assessment
tool.

Figure 3.3
Project Files Overview report

This report presents the projects that were processed by the assessment tool and the
quantity of the different types of modules included in each project. This report can
be useful to identify projects with different types of functionality; for example,
projects that provide user interface elements (with a high percentage of form mod-
ules) or projects that implement the business logic functionality (with a high per-
centage of classes and modules).
User components account for a significant percentage of the upgrade effort; as a
consequence, the inventory of user component definitions and instances declared
must be taken into consideration when determining the inventory of resources to
upgrade. Figure 3.4 illustrates the DetailedReport.xls file and shows an example of
the User Components Summary report.
 Chapter 3: Assessment and Analysis 89

Figure 3.4
User Components Summary report

The User Components Summary report considers all user-defined components and
the lines of code (LOC) contained in each of them. This report also presents the
quantity of instances of each class that are declared in the rest of the user code. The
estimation worksheet generated by the assessment tool also includes a detailed
report of the user components that provides the member usage for each component.
Third-party and Visual Basic 6.0 intrinsic components are also considered in the
application inventory to be upgraded. The upgrade of these components involves
the processing of the application source code to identify accesses to each of the
component members. All member usages will be analyzed to determine if there is an
equivalent member in the target environment; some of these members will not have
an equivalent in Visual Basic .NET and will require additional manual work to be
upgraded to .NET. Figure 3.5 illustrates the Third Party Component Summary
report from the DetailedReport.xls file; it includes all the components used in the
application and the quantity of instances that are created for each class.

Figure 3.5
Third Party Components Summary report

Visual Basic 6.0 intrinsic components are treated in a similar way to third-party
components, with the exception that most of the intrinsic components have an
equivalent in the .NET Framework and most of the member accesses require some
90 Upgrading Visual Basic 6.0 Applications

type of transformation. The inventory of intrinsic components used in the applica-

tion is included in the Visual Basic Intrinsic Components Summary report in the
estimation worksheet generated by the assessment tool.
User COM objects are also included in the inventory to upgrade; the quantity of
occurrences will be considered for effort and cost estimations. It is important to
notice that user COM objects will be considered as third-party components when
accessed from a project different from that in which it was declared.
In the case of user-defined components, there is an important percentage of upgrade
effort dedicated to the processing of the components’ internal code, including
member declarations and usage of features that have a high upgrade cost. Detection
of these features is done by the assessment tool and is included in the estimation
worksheet it generates. The detected features include:
● API calls. The report includes the function name and library in addition to the
data types of the parameters received. One column shows the quantity of usages
of the function in the rest of the code.
● Data access. The report presents the usage of different data access technologies,
including ADO, RDO, and DAO.
● COM+. The report presents a summarized and detailed view of the usage of
COM+ and Microsoft Transaction Server (MTS) classes.
Using the information presented in these reports, it is possible to identify compo-
nents of the application that require special attention in the upgrade planning. For
example, heavy use of ADO recordsets is an indication that a vertical upgrade
strategy should be used for the affected components. For more information about
upgrade planning, see Chapter 2, “Practices for Successful Upgrades,” and Chapter
4, “Common Application Types.”

Source Code Metrics

Typically, the size of an application is defined in terms of the lines of code. Also, the
application source code can be classified and counted according to the origin of the
code; for example, the assessment tool is able to identify code lines related to visual
component declarations, comments, blank lines, and user-written code. The quantity
of lines of code has some limitations as an estimate of the complexity of an applica-
tion from the upgrade perspective. A large application that uses only features
supported by the upgrade wizard can have a low upgrade effort while a small
application that makes extensive use of unsupported features can have a high
upgrade cost. However, source code metrics can still be used to estimate the size and
effort necessary to execute some tasks involved in the upgrade process. These tasks
have a limited complexity and depend mainly on the size of the application and the
quantity of modules and components that form it. Examples of these tasks are the
 Chapter 3: Assessment and Analysis 91

Application Resource Inventory and the Migration Order Definition; both of these
are estimated in the Effort – Total report generated by the assessment tool.
The assessment tool helps to capture source code metrics by producing a report of
the number of lines of code in a project. Figure 3.6 shows an example of the lines of
code (LOC) report in the DetailedReport.xls file produced by the assessment tool.

Figure 3.6
Lines of code (LOC) report

Source code lines are classified by the assessment tool as a result of analyzing all the
content of the application modules. Each line is parsed and classified to determine
how many visual lines, code lines, and comment lines are written in the Visual Basic
6.0 projects processed. Visual lines are lines that were generated by Visual Studio.

Handling Unsupported Features

The upgrade wizard automatically upgrades most of the language constructs and
intrinsic components. It also supports third-party components and different types of
Visual Basic 6.0 projects. However, there are still features that are not fully sup-
ported by the upgrade engine and require some level of manual work to be up-
graded to Visual Basic .NET. The Visual Basic Upgrade Wizard Companion,
available from ArtinSoft, supports many features that are not supported by the
upgrade wizard.
When an application is upgraded, the unsupported features produce different types
of errors in the target application. Compilation or run-time errors can be produced
and user intervention will be required to fix them; this results in the need for re-
sources to review the code, perform the correction, and execute the appropriate
tests.
The assessment tool detects the unsupported features by analyzing the code and
searching for code patterns that will produce upgrade issues after the application is
upgraded. The estimation worksheet has a Config – EWI tab where the cost and
effort values associated with each issue can be reviewed and adjusted according to
specific needs. The values that are initially inserted in this tab are derived from
ArtinSoft’s experience in Visual Basic upgrade projects. The configuration values are
taken into consideration when generating the Effort – EWIs tab in the
MainReport.xls report file, as illustrated in Figure 3.7 on the next page.
92 Upgrading Visual Basic 6.0 Applications

Figure 3.7
Upgrade Issues tab

The Effort – EWIs tab of the MainReport.xls file generated by the assessment tool
reports all the detected issues and the corresponding quantity of occurrences, their
complexities, and cost estimation values. It is important to take into consideration
that the assessment tool does not detect all possible issues that can be generated by
the upgrade wizard; however, most of the issues that have a significant impact on
the upgrade effort are considered. As previously stated, the Config – EWIs tab
includes a column that can be used to adjust the effort value obtained for the up-
grade issues to make your estimates more accurate.

Application Dependences
The assessment tool identifies the dependencies between the application compo-
nents analyzing different aspects of the source code, including:
● Application references. Explicit references to user components indicate that there
is a dependence relationship between different user projects.
● Variable declarations. When a variable is declared using a type that is defined in
a different module or project, a dependence relationship between different
modules or projects is established.
● Member accesses. Member accesses also produce dependences between subrou-
tines, functions, or properties.

The assessment tool identifies dependencies between members of project groups.

When a project references another project that forms part of the same project group,
the assessment tool identifies the referenced project as a user component and in-
forms the user about the relationship between these projects.
 Chapter 3: Assessment and Analysis 93

Knowledge about the usage relationships between components is essential for

different aspects of the upgrade plan, including upgrade order definition, testing,
and debugging. For more information about upgrade planning, see Chapter 5, “The
Visual Basic Upgrade Process.”
Based on the dependence relationships analysis, the assessment tool generates an
Upgrade Order report in the DetailedReport.xls file that includes a suggestion of
the file upgrade order. An example of this report is illustrated in Figure 3.8.

Figure 3.8
Example Upgrade Order report

The report is divided into sections that correspond to each of the application’s
projects. The files in each group are ordered according to the dependences between
the files in the group. The first file in each group has no dependences on other user-
defined files in the same group. As a result, this file can be upgraded and tested
independently. The next file in the list can be upgraded and tested based on the
previous upgraded file.
Each of these files can be upgraded in a staged way, providing increasing levels of
functionality. The assessment tool produces the Upgrade Order report by looking for
modules that depend on the minimum quantity of user components, and then a new
dependency level is generated based on the components included in the previous
level. In this way, each level is built on the functionality provided by previous levels.
This report is useful for identifying possible upgrade paths; if a horizontal upgrade
strategy is going to be used, the suggested upgrade order can be followed. It is also
possible to upgrade modules from different groups at the same time if a vertical
upgrade strategy will be executed for some pieces of the application.

Missing Application Elements

After the initial upgrade preparation steps are complete, it is possible that some of
the application components are not yet available on the computer where the auto-
mated upgrade is going to take place. After these components are identified, it will
be necessary to correct the environment before the upgrade process can be restarted.
These additional steps will consume time and resources that need to be accounted for.
The assessment tool identifies missing application elements that can be reviewed in
the Missing Components and Missing Files reports included in the estimation
94 Upgrading Visual Basic 6.0 Applications

worksheet. Missing elements are identified according to the user defined modules
and explicit references included in the analyzed projects.
Figure 3.9 illustrates the Missing Components report from the DetailedReport.xls
file.

Figure 3.9
Missing Components report

The Missing Components report includes the file name and path of the missing
components in addition to the corresponding version and the registered name. It is
necessary to install these components on the upgrade computer to execute the
automated upgrade. The quantity of missing components is considered in the effort
estimation (Effort – By Tasks tab in the MainReport.xls file produced by the assess-
ment tool) according to the missing elements configuration data.
Figure 3.10 illustrates the Missing Files report from the DetailedReport.xls file.

Figure 3.10
Missing Files report

This report includes the file name, path, and module type for each missing file. The
project where the missing file is detected is also included. In the same way that the
missing components are considered in the estimation effort, missing user files are
also considered.
 Chapter 3: Assessment and Analysis 95

Estimating Effort and Cost

After deciding the best way to upgrade your application, the second goal of applica-
tion analysis and assessment is determining how much effort is actually needed to
upgrade your applications to functionally-equivalent .NET applications. When
estimating effort, you need to include all the steps of the upgrade from the initial
analysis of the requirements up to the deployment of the application and retraining
of developers and users if necessary.
After you have an estimate of effort, you have the most important piece to estimate
the cost of the upgrade. However, the cost of the upgrade also depends on other
elements. One such element is the cost of the people that do the work. Different
parts of the upgrade require people with different profiles. Project administrators,
developers, testers, and architects all cost different amounts of money.
Other things to keep in mind are training, hardware, software licenses, and any
interruptions to your business or the cost of avoiding those interruptions when you
switch to the new version of your application.
The effort estimation reports (Effort – Total, Effort – By Task, Effort – By Resource
Type, and Effort – EWIs) generated by the assessment tool provide configurable
parameters that help fine-tune a calculation of the effort and time required to com-
plete the upgrade of a project. This report is created along with all the application’s
technology details.

Methodology Overview
It is important to understand the concept of effort in the upgrade context. The effort
of each task is expressed in hours that correspond to normalized time, that is, it
corresponds with the time that the task would take if it was executed using average
resources. If there is a highly experienced programmer in charge of that task, it will
be finished in less time. In addition to average resources provided by default, the
Effort Estimation report includes parameters such as junior developer, junior tester,
senior developer, and senior tester; each with a different cost per hour.
The cost of most tasks is directly derived from the cost of the resources necessary to
perform the tasks and the estimated effort required to execute the task. For example,
the cost of upgrading a COM component is higher if a senior developer is respon-
sible for the conversion, although this may result in reduced effort. In contrast, a
junior developer will cost less than an experienced developer but will require more
time to achieve a functionally-equivalent upgrade. For more specific tasks, the cost
is obtained from a per-occurrence cost that is related to the each task’s degree of
difficulty and the kind of resources necessary to perform it. The Config – General
tab in the MainReport.xls file generated by the assessment tool contains default
values for cost and effort for different upgrade tasks. These values can be modified
96 Upgrading Visual Basic 6.0 Applications

to match more closely to your own development capabilities and costs. Figure 3.11
illustrates the Config – General tab.

Figure 3.11
Config – General tab

Some tasks directly depend on the number of lines of code that comprise individual
components or files. The estimated effort is the number of lines of code multiplied
by some constant. This constant is based on work performed on previous upgrade
projects involving various different types of applications.
For tasks whose cost is derived from the quantity of occurrences of a feature, the
application conversion estimate of effort is calculated by counting up all features’
occurrences within the project and adding the cost to upgrade each occurrence and
the effort per occurrence in terms of time. This is included on the Effort – By Task
tab in the MainReport.xls file generated by the assessment tool, with totals reflecting
time and cost for all occurrences of each feature. Figure 3.12 illustrates a sample of
this tab.
Each EWI has an effort and cost associated with it. All these values are derived from
the steps necessary to resolve each issue in other upgrade projects. These values can
be configured on the Effort – EWIs tab in the MainReport.xls file. An example of this
table is shown in Figure 3.13.
This tab allows you to change the default effort and cost associated with each EWI to
help you prepare a more accurate estimate of the effort required to address upgrade
issues.
 Chapter 3: Assessment and Analysis 97

Figure 3.12
Manual Code Adjustment Effort tab

Figure 3.13
Effort – EWIs tab

Aspects to Be Estimated
The different phases to be estimated relate directly to the steps of the upgrade
procedure. In summary, the items to be estimated are:
● Project kickoff. This includes the estimated time for the upgrade project kick-off
meeting. Typically, it is not a large value. It serves as a reminder that these cost
estimates have a well-defined scope. It also reminds you of the many things that
you must do before the upgrade project begins, such as training, research, and
purchasing software and hardware, which are not included here.
● Application preparation. This includes the estimated time for the setup and
verification of the development environment of the original application. This
includes compilation of the original application to verify that it is complete and
source code modifications to accelerate the conversion process later on.
● Application conversion. This includes the estimated time for the execution of the
upgrade wizard and completing the upgrade with manual changes.
● Testing and debugging. This includes the estimated time for the execution of the
original test cases and fixing any run-time errors.
98 Upgrading Visual Basic 6.0 Applications

● Project management. This includes the estimated time for administrative tasks
related to scheduling and management.
● Configuration management. This includes the estimated time for configuration
management of the products obtained throughout the entire upgrade process.
For more information, see Chapter 5, “The Visual Basic Upgrade Process.”
The application composition is the inventory to be upgraded; this is reflected on the
Project Files Overview tab. The inventory of the application is the first aspect to be
considered when estimating the upgrade effort. This inventory will provide a
general vision of the projects and modules to be upgraded. The content of these
modules will be detailed in the Effort Estimation report. The application composi-
tion is an important report to plan the rest of the upgrade and set priorities for the
different projects and modules. For instance, if there are several user controls that
present a dependency among classes, it is wise to set a high priority to those compo-
nents to have them ready when upgrading the forms and classes that depend on
them.
As mentioned in the “Methodology Overview” section, the Config – EWI tab
includes an estimation of the effort needed to upgrade an issue. The values provided
by the assessment tool and that are generated as part of this tab affect the following
worksheets:
● Effort – EWIs

● Effort – By Task

● Effort – Total

The Effort – By Task tab consolidates different aspects of the effort estimation,
including features/code items such as property pages, designers, third-party com-
ponents, ADO, RDO, COM, COM+, and more. Each element is a summary of more
detailed information that can be found in the DetailedReport.xls file.
The tasks included on the Effort – By Task tab have a high degree of detail behind
them, and the estimation is calculated as a function of the data in the details. The
types of resources used to perform the different tasks are also explicitly indicated in
this report to give an idea of the level of experience that each task will likely need,
and the subsequent cost.

Understanding the Effort – Total Worksheet

A complete summary of the effort and cost estimations can be found on the Effort –
Total worksheet in the Microsoft Excel workbook that is generated by the assess-
ment tool.
Before looking at the worksheet in detail, be aware that it generates an estimate that
you must fully review and customize before you use it in your own project estima-
tions. Although almost every aspect of your application is covered somewhere in
 Chapter 3: Assessment and Analysis 99

this workbook and each has an associated weight indicating the effort required to
upgrade that particular aspect, the weights for some aspects are left at zero. This
means that the assessment tool does not consider that all aspects are important to
the estimation. The aspects that do have weights for effort and cost have values that
may not be appropriate for your organization. Also, remember that every upgrade
project is different, and although similar worksheets to this one have been used in
real upgrade projects, there are always new things to consider or assumptions built
into estimate worksheets that do not apply to every project. It is likely that you will
have to make some adjustments before applying this estimation to your own
projects. For this reason, the next paragraphs explain how the assessment tool
arrives at the cost estimation it produces in the Excel workbook. Every effort has
been made to base the estimates on projects that are as close as possible to typical.
The formulas and weights in Figure 3.14 are based on experience with real upgrade
projects and accurately reflect that experience.

Figure 3.14
Effort –Total tab

The Effort – Total worksheet is divided into three sections: “Application prepara-
tion,” “Application conversion,” and “Testing and debugging.” Each section will be
examined in detail. However, please keep the following notes in mind:
● Most cells in the Effort (Hours) column are references to named cells on the
General Configuration tab or are functions of named cells from there. If you
100 Upgrading Visual Basic 6.0 Applications

make any changes, it is recommended that you make those changes to the Gen-
eral Configuration worksheet instead of to the Effort worksheet.
● Any cell or set of adjacent cells can be given a name and used in formulas. You
will see names used as if they were single values (for example, =NameA+NameB)
and collections of values (for example, =SUM(NameC)).
● For consistency, the worksheets and formulas are organized so that you will only
ever need to change either the General Configuration worksheet or the EWI
Configuration worksheet. The General Configuration worksheet is referenced
primarily in the Total Effort worksheet, and the EWI Configuration worksheet is
referenced mostly in the Upgrade Issues Table worksheet. However, it is okay to
change the other worksheets if you want to. A third worksheet that you will
likely have to change is the Resource Costs worksheet, which specifies how much
it costs for different types of people to work on the upgrade project. These values
change from country to country, from business to business, and even from month
to month, so you will probably have to review them.
Be careful when you make changes to the worksheets generated by the assessment
tool; when it runs again, it will create a new workbook, possibly overwriting all
your changes. Always keep a backup of the workbook file before re-running the
assessment tool. It is recommended that you only make changes to the
MainReport.xls file and keep a backup of it. You can easily change the MainReport
file to link to any DetailedReport.xls file. This saves you from having to reconfigure
the assessment tool or copy configuration information between reports.

Application Preparation
The application preparation phase is described in detail in Chapter 5, “The Visual
Basic Upgrade Process.” In the context of this discussion, the definition of applica-
tion preparation is broadened to include everything from the moment that you are
preparing the computers the upgrade will be performed on up to just before the
upgrade wizard runs for the last time to generate the initial code that will be used as
the source base for the new Visual Basic .NET application.
This does not include the time spent studying alternatives or any of the other activi-
ties that are performed before an upgrade project is approved. It is assumed that the
decision to upgrade has already been made and that the upgrade project has been
approved.
Nor does it include any “code preparation” activities that are described in Chapter 5,
such as running the Visual Basic Code Advisor to clean up the code to make it more
amenable to upgrade. These activities can help reduce overall upgrade time but
including them in these estimations would make them overly complex. We suggest
that you use the assessment tool after you do any code preparation. If your code
preparation is successful, you should see a reduction in the effort estimated by the
assessment tool before and after code preparation is complete.
 Chapter 3: Assessment and Analysis 101

Most of the tasks in this phase have fixed estimations of effort and cost or have
estimations based on the number of lines of code in the application. These are
explained here:
● Development environment. This includes the setup of the upgrade wizard,
which will be used to analyze and upgrade the application. This effort is fixed
and configurable by the user of the assessment tool.
● Application resource inventory. This includes an initial review of the application
and gathering all the files and tools that are needed to compile the application in
Visual Basic 6.0. It also includes time for collecting existing information about the
applications architecture and design. This value depends on the size of the
application.
● Compilation verification. The original application is compiled to verify that all
the required files are available. This effort is fixed and configurable by the user of
the assessment tool.
● Upgrade order definition. The upgrade order is determined by the assessment
tool reports and priorities that are implied by your own strategic and technical
goals. This value also depends on the size of the application.
● Upgrade wizard report review. Preliminary test upgrade of the application to test
the system resources and detect common errors and practices that are more easily
fixed in Visual Basic 6.0. This task also depends on the size of the application.

Application Conversion
The application conversion phase includes all the tasks required to get the green code
to functional equivalence. Green code is the name for the unmodified code gener-
ated by the upgrade wizard that serves as the initial code base for the upgrade.
The tasks in this phase are:
● Upgrade wizard execution. This involves execution of the upgrade wizard to
obtain the green code. This effort depends on the size of the application.
● Issue resolution. This involves manual resolution of all the issues mentioned in
the Effort – EWIs worksheet. This sheet is described in greater detail later in this
chapter.
● Code review. After all the issues are resolved, it is necessary to integrate all the
new code, compile it, and debug it.
● Administrative tasks. This involves administrative tasks performed during this
phase, such as scheduling and resource assignment. It is calculated as a percent-
age of all the other tasks in this phase.
102 Upgrading Visual Basic 6.0 Applications

Testing and Debugging

The last phase includes all the quality assurance tasks that must be preformed to
ensure that the application is functionally equivalent to the original application. All
the tasks in this phase are calculated as percentages of the total effort in the Applica-
tion Conversion phase. These tasks are:
● Test case creation. This task involves creating new test cases or adapting existing
test cases to be used for quality assurance and to verify functional equivalence.
● Test case execution. This includes multiple executions of the test cases during
testing as the application moves toward functional equivalence.
● Run-time error correction. This task includes bug fixes, workarounds, and other
resolutions of detected run-time errors.
● Administrative tasks. This task includes bug management, test case manage-
ment, regression testing, and other administrative tasks that are typically associ-
ated with testing and debugging.

Understanding the Estimate

As previously stated, estimating development projects is traditionally a very diffi-
cult thing to get right. The reports and estimations generated by the assessment tool
are based on extensive experience with upgrade projects and take into account as
much detail as possible from that experience. Tasks outside the three phases ex-
plained earlier are not included.
After the most important tasks are known, you must decide how much time each
task will require. The assessment tool estimates are only suggestions based on
developer experience. You should review all of the features identified in the report
and the amount of time allocated to each one. It may be necessary to modify these
estimates if they do not reflect your organization’s experience; for example, if you
have no one with experience in that area and believe more time is required or if you
have already solved the problem before and are confident it can be done more
quickly.
Also keep in mind that unforeseen issues can occur. You may be using a third-party
library that is not taken into consideration by the assessment tool, or your applica-
tion may make unconventional use of some Visual Basic 6.0 features or behaviors
that was not considered by the assessment tool.
For these reasons, you should consider the numbers generated by the assessment
tool as a rough estimate. You can get more accurate results by reviewing all the
issues identified by the assessment tool and making sure that the effort assigned to
each individual issue makes sense in your organization. Also, be certain to obtain
your developers’ approval of the estimation because they are the ones that have to
deliver in the end.
 Chapter 3: Assessment and Analysis 103

Understanding the Configuration Settings

This section describes the configuration settings for the assessment tool. Each of
these settings can be found in the MainReport.xls file that is produced by the assess-
ment tool.

Config – General
The Config – General tab allows you to configure the estimated effort for specific
upgrade issues, such as correcting and verifying every 1,000 lines of code. It includes
the following columns:
● Migration Task. This column includes tasks that must be performed during the
upgrade. Some of the tasks refer to specific characteristics of the application (such
as lines of code) or types of components used by the application (such as COM
objects or ADO).
● Effort per occurrence (Hours). This column defines the time required to upgrade
an occurrence of an upgrade task, measured in hours. This value should be
configured to reflect the capabilities of the developers in your company. The
default value is usually a good average.
● Cost per hour. This column identifies the cost per hour of upgrading an occur-
rence of one of these issues. This is highly variable and depends on the skill level
of the person that will be working on each issue and the salary levels for someone
of that level.
● Resource. This column identifies the recommended resource type that should be
assigned to resolving each issue.
● Description. This column provides a description for each upgrade task.

Config – By Resources
Resource costs can be found in the Config – By Resources tab. They represent an
estimation of development resources required to resolve an upgrade issue. Figure
3.15 shows an example Config – By Resources tab.

Figure 3.15
Config – By Resources tab
104 Upgrading Visual Basic 6.0 Applications

The Config – By Resources tab includes the following four columns:

● Resource. This column names different levels of experience and skill that may be
needed during an upgrade.
● ID. This column identifies an abbreviation for this type of resource that is used in
other tables in the report.
● Cost per hour. This column specifies the cost per hour associated with each
resource. As mentioned earlier, this is highly variable and should be modified to
reflect your own costs.
● Description. This column contains a description of each type of resource.

Config – Fixed Tasks

The Config – Fixed Tasks table introduces a set of processes to be accomplished in
any upgrade project by the resources listed on the Config – By Resource tab. Figure
3.16 shows an example of this tab.

Figure 3.16
Config – Fixed Task tab

The Config – Fixed Tasks tab includes the following three columns:
● Task. This column lists some common tasks that are a part of every upgrade
project.
● Hours. This column lists the time required to complete each task. Again, this may
need to be changed to reflect you own circumstances.
● Description. This column provides a description of each task.

Config – EWIs
The Config – EWIs tab displays information about the upgrade estimates for EWIs.
It includes the following seven columns:
● Name. This column contains the name of each error, warning, and issue.

● MSDN ID. This column contains the Microsoft Developer’s Network ID of the
EWI.
● Resource. This column identifies the recommended resource type that should be
assigned to resolving each EWI.
 Chapter 3: Assessment and Analysis 105

● Effort per occurrence (Minutes). This column defines the time required to up-
grade an occurrence of an upgrade EWI measured in minutes. This value should
be configured to reflect the capabilities of the developers in your company. The
default value is usually a good average.
● Effort per occurrence (Hours). This column is the same as the preceding one,
except the time is displayed in hours instead of minutes.
● Cost per hour. This column identifies the cost associated with the upgrade of
each issue by an average developer. This is highly variable and depends on the
skill level of the person that will be working on each issue and the salary levels
for someone of that level.
● Functionality. This column contains a more detailed description of the EWI.

Summary
A successful upgrade project depends on careful assessment and analysis of the
project to upgrade. A thorough application of these tasks ensures accurate planning
and budgeting. This chapter discussed the information you need to gather to per-
form these tasks and some of the tools available to help you gather it.

More Information
For more information about improving the performance of your applications, see the
white paper titled “Advantages of Migrating from Visual Basic 6.0 to Visual Basic
.NET” on MSDN:
http://msdn.microsoft.com/vbasic/productinfo/advantage/default.aspx.
For more information about the Visual Basic Companion from ArtinSoft, go to the
ArtinSoft Web site:
http://www.artinsoft.com/Default.aspx.
4
Common Application Types
This chapter can help you to understand how common Visual Basic 6.0 application
types are treated before, during, and after an upgrade. The chapter explores the
dependencies between an application type and the application’s actual architecture
from an upgrade perspective. After you have made the decision to upgrade, use this
chapter to learn about the similarities and differences between Visual Basic 6.0 and
Visual Basic .NET application types, and how to achieve a smooth transition that
takes advantage of features available in the upgraded version.

Identifying and Upgrading Application Types

You can learn about your application and the process of upgrading it by comparing
it to other applications with similar requirements and architectures. By selecting an
application type, you choose a set of capabilities and characteristics that are well
suited to the problem that your application solves. Application types are character-
ized by traits such as audience, intended use, architecture, and capabilities.
In Visual Basic 6.0, there are a variety of application types to choose from. These
application types can be divided into two categories: application components and
full application executables.
The Visual Basic Upgrade Wizard supports different Visual Basic 6.0 application
types, including standard executables (.exes), ActiveX components, and Internet
Information Services (IIS) applications. Depending on the original project type, the
upgrade wizard generates a .NET project whose output is a Windows-based applica-
tion (.exe) or a class library (a dynamic link library, or DLL).
To get the most out of the services and features in the .NET platform, you should
evaluate the architecture and type of your upgraded application. For example, you
can transform a highly coupled or monolithic desktop application into an applica-
tion that includes several independent components in well-defined tiers and takes
advantage of technologies provided by Visual Basic .NET. This kind of improvement
is discussed in detail in Chapter 17, “Introduction to Application Advancement.”
108 Upgrading Visual Basic 6.0 Applications

Determining Application Type and Functional Equivalency

When you upgrade your application, your first goal is to achieve functional equiva-
lence between the legacy and upgraded versions. The equivalency between Visual
Basic 6.0 and Visual Basic .NET application architecture and project type is shown in
the Table 4.1.
Table 4.1: Application Type Equivalency Table
Application Architecture Visual Basic 6.0 Project Type Visual Basic .NET Project Type
Desktop application Standard executable Windows-based application
Web application Internet Information ASP. NET Web application
Service (IIS) application
Distributed application Application that uses Application that uses components
distributed component object of System Runtime Remoting and
model (DCOM), Microsoft System Enterprise Services .NET
Transaction Services (MTS), Framework namespaces
or COM+ services

This chapter provides a high-level summary of the upgrade process for each applica-
tion architecture and type.

Determining Component and Project Types

Visual Basic applications are built with different components that provide the basic
functionality and services that the applications require. Some components can be used
in different application architectures; for example, an out-of-process reusable compo-
nent library can be used in a desktop application or in a distributed application.
Table 4.2 shows how component types correspond to Visual Basic project types.
Table 4.2: Components and Corresponding Project Types
Component Type Visual Basic 6.0 Project Type Visual Basic .NET Project Type
Reusable library ActiveX .exe No direct equivalent: upgrade to
(out-of-process) Windows-based application or
class library project.
Reusable library ActiveX DLL Class library
(in-process)
Visual application ActiveX control Windows control library
component
Visual application ActiveX document No direct equivalent.
component to be hosted Re-implement using .NET Frame
in an Internet application work components such as
UserControls and XML Web forms.
 Chapter 4: Common Application Types 109

For a summary of how to upgrade these component types, see the “Application
Components” section later in this chapter.

Desktop and Web Applications

Desktop and Web applications are two basic frames that include all of the compo-
nents and source code that make up an application. When you upgrade a desktop or
Web application, you should consider the components and their interconnections,
the structure of each component, and the overall application architecture.
This section first explains upgrade considerations that are common to both desktop
and Web applications, and then concentrates on specific aspects of each application
type.
A desktop application can require considerable effort to upgrade to the .NET Frame-
work. One of the difficulties in upgrading an application is because Visual Basic has
been completely redesigned for the .NET Framework, and functions and controls do
not correspond exactly to their counterparts in Visual Basic 6.0.1

Architecture Considerations
As explained in Chapter 2, “Practices for Successful Upgrades,” you may need to
approach the upgrade by using one of the following two approaches:
● Vertical upgrade. This approach requires that you isolate and replace a piece of
your application through all n tiers.
● Horizontal upgrade. This approach requires that you replace an entire tier of
your application.
To assure functional equivalence independently of your chosen approach, you must
have comprehensive unit and system test suites for the entire application, as well as
for individual upgrade modules, components, or tiers. You may find it convenient to
upgrade portions of the application that you can test in the early stages of the
process. This approach allows you to have different developers or development
teams work in parallel, and it helps you to correct issues early in your project.
However, as explained in the forthcoming sections, it is not always feasible to
independently upgrade and test pieces of an application.
For more information about testing and debugging an upgraded application, see
“Testing and Debugging the Upgraded Application” in Chapter 5, “The Visual Basic
Upgrade Process,” and Chapter 21, “Testing Upgraded Applications.”
110 Upgrading Visual Basic 6.0 Applications

Single-Tier Applications
Single-tier (or monolithic) applications are applications in which most or all of
the code for a given feature is contained in a single source code file. In Visual Basic,
this usually means that all of the functional logic is in the control event handler
subroutines. All necessary components and functionality are included in a group of
forms, making them the conceptual units for the application features. In such appli-
cations, development tends to be driven by the user interface. If new features are
needed in the application, new components are built into existing forms. For ex-
ample, when a single-tier application requires database access, then a component for
data access is plugged into the form, and all methods that need to access the data-
base use the newly integrated component.
Single-tier applications do not have separate functional layers for data access,
business logic, or the user interface. All necessary services and components are
integrated in the same development unit (usually a form). This kind of application is
highly coupled because all components are closely tied together, usually in the same
file or procedure, with many shared structures and connection points. A single-tier
application also has low cohesion, which means that the mechanisms that constitute
different conceptual entities are so closely tied together that conceptual barriers are
obscured. This makes modifying functionality difficult because making a change can
affect more than just the intended functional behavior.
When you compile an application of this type, you generate a single executable file
that contains all of the necessary information for user-defined forms and modules.
To deploy such an application, you must install the executable file and any related
third-party components on each of user computer.
The remainder of this section describes issues that you should consider when you
upgrade a single-tier application.
Although the example uses a single multiple-document interface (MDI) child form,
the concepts presented also apply to solutions composed of several forms and
modules and to Web applications that are highly coupled.
The form in this example (which could just as easily be a Web page) allows a user to
have a general overview of the telephone calls received at an IT help desk. After the
user locates a record, he or she can request more information about it. The form
contains a data-bound grid that displays records in a table with telephone call data.
The grid uses an ActiveX Data Object (ADO) data control as its data source: the data
control provides the communication with the system’s database. Because the form
displays the full list of calls, the control has been made invisible. Figure 4.1 provides
an overview of the form components and architecture.
 Chapter 4: Common Application Types 111

IT Help Desk application

Telephone call search form

Visual behavior Other visual

code components

DataGrid

Business logic Data Control ADO

Database

Figure 4.1
Typical monolithic form components

The outer box represents the single tier application, which contains the telephone
calls search form. This form includes components for data access, business logic, and
visual components, represented in the diagram by the smaller boxes. The arrows in
the diagram show the dependences between components. The visual behavior code
manages the rest of components, The DataGrid control uses an ADO data control to
display the information extracted from the database. The business logic interprets
the telephone numbers if a user requests details about a call. Although the boxes
related to business logic and data access are shown as independent entities, the
corresponding code could be intermixed with the rest of the form’s code. Note also
that all of the functionality is enclosed in the telephone call search form and cannot
be used by any application modules outside this form.
Because the complete functionality of this example is encapsulated in a single form,
it must all be upgraded and potentially adjusted before the form can be compiled,
executed, and tested. For example, the business logic included in the form cannot be
upgraded and tested independently of the rest of the code unless the developer
rearchitects the original form. The monolithic structure of the application makes an
incremental upgrade and test of isolated functionality extremely difficult. The form
and all its elements must be upgraded as a single functional unit that constitutes the
entire application. In this sense, the upgrade strategy to be followed for a monolithic
application is a complete upgrade strategy.
112 Upgrading Visual Basic 6.0 Applications

Redesigning Your Single-Tier Application

When you upgrade a single-tier application, your best strategy is to redesign the
application and separate its functionality into distinct parts. This approach provides
modularity and functional cohesion, making it easier to modify pieces of the appli-
cation, add or remove functionality, or make functionality available to other applica-
tions.
Using a vertical strategy to upgrade parts of your application to the new architecture
provides an effective test bed for the new design. The .NET Framework provides
architectural support that makes it much easier to build on an upgraded base. (Note
that using a vertical strategy also applies to two and three tier applications.)
After you use a vertical approach to upgrade part of the application, you can use
interoperability to integrate some of the managed code and the existing unmanaged
code. Be careful when you choose which portion of the application to upgrade,
because the choice may affect development costs. For example, the cost to integrate
a managed form and a group of unmanaged business classes, which can be done
through interoperability, is low compared to the costs associated with integrating
managed and unmanaged forms that need to interact. This last kind of integration
could require increases development costs because of different event models and
a user-defined communication and marshaling scheme between managed and
unmanaged forms code.
After you have integrated a subset of the application functionality, testing is neces-
sary to ensure that the new and old pieces of the application work together, share
data, and provide a seamless experience to the end user or client developer. After
successful testing, you will have a basic infrastructure, and you can continue with
the vertical upgrade of the application components.
In most cases, you should restructure an application after you have executed an
automated upgrade and achieved functional equivalence. This approach allows you
to take advantage of the improved Visual Basic .NET features. However, depending
on the features supported by the Visual Basic Upgrade Wizard or other automated
upgrade tools, you may need to make some structure and component changes
before you can automatically upgrade your Visual Basic 6.0 source code. You may
need to reorganize the code and replace unsupported classes with supported ones so
that the upgrade wizard can apply all the necessary mappings and transformations.
For example, data access object (DAO) and remote data object (RDO) components
can be slightly reorganized and changed to ADO, which has better support in the
Visual Basic Upgrade Wizard and other automated upgrade tools. For more infor-
mation about upgrade wizard unsupported functionality or about data access
component upgrades, see Chapters 7 – 12.
The equivalent .NET application architecture for the upgraded application is a
Visual Basic .NET Windows-based application project whose startup object corre-
sponds to the original Visual Basic 6.0 object. (The Visual Basic Upgrade Wizard
 Chapter 4: Common Application Types 113

generates a NET solution file that contains only this project.) When the wizard
upgrades a typical single-tier application, it replaces all library references with
references to the common equivalents in the .NET Framework base class library.
References to the System namespace provide basic functionality for the Form class
and XML capabilities. The Microsoft.VisualBasic assembly provides functions that
are similar to the functions available in the Visual Basic 6.0 VBA library. Each class
library that was referenced in the original application will have a corresponding
reference in the Visual Basic .NET project. ActiveX control (.ocx) components will
have an additional reference that begins with the prefix Ax and corresponds to a
Windows Forms control wrapper. These references are generated by the aximp
utility. For example, a reference to the component MSComctlLib for common
controls results in a new reference to AxMSComctlLib. This additional reference
provides support for the native members and behavior that all Windows Forms
controls support.
The upgraded application will have the same structure as the original. All of the
original relationships between application components are in the upgraded version.
The Visual Basic Upgrade Wizard automatically generates interoperability wrappers
for all ActiveX components that require it. For example, in the telephone calls
example form described earlier, a wrapper is generated for the DataGrid and ADO
components. For more information about interoperability, see the “Application
Components” section later in this chapter.
It is important to note that the remaining components are upgraded to native .NET
Framework classes, and most of the source code is converted to Visual Basic .NET.
You can manually upgrade the wrapped ActiveX components to native .NET com-
ponents after applying the automatic tools. For example, you can upgrade ADO to
ADO.NET and upgrade the DataGrid control to the .NET Framework DataGrid or
to a third-party data grid. However, manual adjustments require more time and
effort to achieve.

Two-Tier Applications
A two-tier application is composed of a first tier — the user interface tier — that
contains a user interface and business logic, and a second tier — the data tier — that
contains all of the data access components. The user interacts with the interface tier,
and uses it to perform all application-specific functions. The data tier contains all
data sources and manages them so that they can provide all necessary data services
to the user interface tier.
The user interface of a Visual Basic 6.0 application can contain forms, Web pages,
or both. Additionally, a Visual Basic 6.0 application can have a front end that can be
accessed programmatically. In addition, enterprise applications can have rich forms
clients as well as thin Web clients that can be accessed remotely.
114 Upgrading Visual Basic 6.0 Applications

Figure 4.2 shows a two-tier application form based on the telephone list and filter
window explained in the previous section. In this example, the data access compo-
nents are no longer part of the form module. Instead, they are defined indepen-
dently, which allows for modularity and code reuse. This architecture also offers
more upgrade alternatives than the single-tier architecture. The separation of tiers
permits each tier to be upgraded and tested independently. This gives more flexibil-
ity to the upgrade plan.
A two-tier application can be upgraded horizontally or vertically. If you select a
horizontal strategy, you can update an entire tier and leave the remaining tier
unchanged. The upgraded tier can use interoperability features to work with the tier
that was not upgraded. You can then upgrade the remaining tier and integrate it into
the target application as time and budget permits. Alternatively, you can use a
vertical upgrade strategy as explained in the previous section.

Telephone call search form

Visual behavior Other visual

code components

DataGrid

Business logic Data Control

UI Tier

Data Tier
Data Access
Class

ADO

Database
Figure 4.2
Typical two-tier application architecture
 Chapter 4: Common Application Types 115

When you upgrade a two-tier application, the upgrade wizard produces a Visual
Basic .NET project that contains files and references similar to those produced for a
single-tier application. The main difference is that a data access class is included in
the project files. This class is independent of the other classes and provides services
that can be used by any other class. This class contains some wrapped classes that
correspond to low-level data access classes (ADO) to provide basic services. If you
manually upgrade ADO to ADO.NET, you must also change this data access class.
However, if your application was designed in a modular way (with low coupling),
you need to make only minimal changes to the rest of the application because
internal changes in the user-defined data access class will not affect its users.

Three-Tier Applications
A three-tier application maximizes component cohesion and minimizes tier cou-
pling. This architecture uses three different tiers for the different aspects of the
application: a user interface tier, a business logic tier, and a data tier. The difference
between a three-tier and a two-tier application is the addition of a business logic tier.
The business logic tier contains application rules and algorithms; therefore, the user
interface tier is only responsible for managing the interaction between the user and
the application. The business logic tier can be segmented into additional logical tiers
to produce a multi-tier architecture. The components of the business logic tier can
also have a close interaction with the data tier. Figure 4.3 on the next page shows a
typical three-tier application.
Because of the further separation of tiers, an upgrade strategy for a three-tier appli-
cation can be even more flexible than an upgrade strategy for a two-tier application.
As with two-tier applications, a three-tier application can be upgraded in a horizon-
tal or vertical way. By using a horizontal strategy, you can upgrade all or part of a
tier and leave the other tiers unchanged. The upgraded code can use interoperability
features to access the unchanged code. Then, you can gradually upgrade the other
tiers and integrate them into the application.
Another important feature of a three-tier architecture is that it allows you to take
advantage of specialized skills that your developers may have, and have them work
in parallel. For example, one developer or development team could work on modu-
lar user interface components while other developers upgrade and adjust the com-
ponents in the business logic and data access tiers.
When you upgrade a three-tier application, the resulting application will also have
three tiers. The upgrade wizard generates ActiveX wrappers for components used in
the UI tier. It is probable that you will need to perform additional UI testing because
some of the UI components require wrappers, custom upgrades, or reimplementa-
tion. However, you can reduce the associated risks by upgrading the UI tier first and
connecting it to the other tiers by using interoperability, while you test the UI tier
early in your project. This approach allows you to upgrade, test, and integrate the
116 Upgrading Visual Basic 6.0 Applications

other tiers in parallel. For additional advice about which tier to upgrade first, see
Chapter 2, “Practices for Successful Upgrades.”

Telephone call search form

Visual behavior Other visual

DataGrid
code components

UI Tier

Business
Logic Tier Business logic

Data Tier
Data Access
Class

ADO

Database
Figure 4.3
Typical three-tier application architecture

Most of the effort to deploy an upgraded three-tier application is spent on setting up

the system servers. You must set up application and data servers to allow the clients
to access the application. Client setup is simpler because most of the components are
installed on the servers, and client computers use an Internet browser to access the
application.
 Chapter 4: Common Application Types 117

Desktop Applications
To create a Visual Basic 6.0 desktop application, you use the standard executable
project template. By default, this template starts with an empty form that becomes
one of the primary interfaces. The Visual Basic 6.0 integrated development environ-
ment (IDE) allows you to include supplementary components and references to take
advantage of existing functionality.
A typical desktop application that uses a highly coupled architecture consists of a fat
client, possible middle-tier COM components with business logic, a data access tier,
and a connection to a data store. In this type of application, the presentation and
business logic reside on the client.
In general, a desktop application had the following characteristics:
● Intended usage. The application has many visual cues or aids and provides a
complex interaction with the user.
● Architecture. The application architecture is flexible: for example, it can be a
single tier, fully coupled application or a completely modular application with
well-defined business logic and data access tiers.
● Necessary capabilities. The application requires user interface components, basic
services, and data access functionality. Multithreading capability may be re-
quired, but synchronized process distribution is rarely needed unless the applica-
tion uses the distributed component object model (DCOM) or COM+.
The Visual Basic 6.0 to Visual Basic .NET Upgrade Wizard automatically upgrades
desktop applications to be Visual Basic .NET Windows-based applications. The
wizard does not change the general organization of the code. Therefore, the original
application tiers remain intact. However, there are architecture-related issues that
you should consider when you upgrade a desktop application. These issues include
the following:
● Language issues. You may need to perform additional manual upgrading to
resolve language issues, such as external DLL function declarations or thread
safety. This work can include creating or changing classes so that they provide
basic API services or synchronization among objects. You can upgrade external
declarations to .NET Framework classes and new interface classes. In addition,
you may need to add references. Note that Visual Basic .NET components (in-
cluding UserControls) are not inherently thread-safe. Multiple threads are
allowed to access a component simultaneously. As a result, code that is thread
safe in Visual Basic 6.0 can be unsafe when it is upgraded to Visual Basic .NET.
This change will affect you if you are running your component in a
multithreaded environment such as Internet Explorer, Internet Information
Services, or COM+.2 In this case, you must include new synchronization mecha-
nisms to ensure thread safety.
118 Upgrading Visual Basic 6.0 Applications

● Forms issues. Dynamic data exchange (DDE) and drag-and-drop functionality

can cause upgrade issues. Neither Visual Basic .NET nor the .NET Framework
support DDE. Because Visual Basic drag-and-drop is considered an outdated
feature, the upgrade wizard does not upgrade drag-and-drop – related code.
Instead, it preserves the Visual Basic 6.0 drag-and-drop code in the upgraded
Visual Basic .NET project. The code will not compile; therefore, you must either
delete it and remove the drag-and-drop functionality or change the code to use
OLE drag and drop. For more information about these issues, see Chapter 9,
“Upgrading Visual Basic 6.0 Forms Features.”
● ActiveX control upgrade. The upgrade wizard supports most ActiveX compo-
nents. The upgrade of these components takes advantage of the interoperability
that can be built around the original component. However, if an application
control is not supported, you must reimplement and re-architect some applica-
tion functionality, particularly in the user interface. In applications that make
extensive use of complex third-party controls, you should perform limited
upgrade tests with a simplified user interface. This will help you to determine
how many controls are fully or partially supported.

For Visual Basic 2005:

The Visual Studio 2005 version of the Visual Basic Upgrade Wizard will up-
grade more ActiveX controls to .NET native controls rather than wrapped
controls. The additional supported controls (which are contained in the Micro-
soft Windows Common Controls library) include: ToolBar, StatusBar,
ProgressBar, TreeView, ListView and ImageList.

To deploy an upgraded .NET desktop application, you must do the following:

● Install the application executable and library files on the client computer.

● Use the .NET Framework Assembly Registration Utility (regasm) to register

the.NET Framework library assemblies that are shared by different applications.
● If the application contains ActiveX components, register these components on
each client computer.
● Distribute all the corresponding ActiveX wrapper assemblies.

Web Applications
In most cases, you would use the following technologies to build a Web site or Web
application with Visual Basic 6.0:
● Active Server Pages (.asp). This is a server-side scripting run-time environment
used to create interactive Web server applications. An .asp file can include HTML
sections, script commands, and COM components that execute on the Web server
and render a Web page for the client.
● Internet Information Server (IIS) projects. These are applications composed of
WebClasses that run on the Web server and respond to HTTP requests from
 Chapter 4: Common Application Types 119

clients. WebClasses can handle state information for the application. For more
information about upgrading an IIS project, see Appendix C, “Introduction to
Upgrading ASP,” and Chapter 10, “Upgrading Web Applications.”
The functionally equivalent server-side technology in Visual Studio .NET is
ASP.NET. This is not simply a new version of ASP. It has been entirely redesigned
based on the .NET Framework. This section highlights the main considerations that
you should take into account when you upgrade ASP code to ASP.NET.
Figure 4.4 shows the general architecture of a Visual Basic 6.0 Web application.
A client Web browser sends a request to IIS, and IIS responds by rendering active
server pages. The ASP files access COM components that contain part of the
application’s business logic and data access layers. These components run in the
Web server computer or in an application server. The larger, background boxes
represent platform servers that provide functionality to different conceptual tiers;
for example, the Web server box includes business logic functionality and part of the
user interface functionality because it has to provide presentation elements as well
executable code in ASP files. The ASP files include application logic and presenta-
tion elements in a single module; that is why the active server pages box crosses the
barrier between the UI tier and the business logic tier.

Web Browser

Web Server
UI Tier
Active Server
Pages

Application Server
Internet
Business
Information Business Logic
Logic Tier
Services Components

Data Tier

Data Access
Class
Database

Figure 4.4
Visual Basic 6.0 Web application architecture
120 Upgrading Visual Basic 6.0 Applications

Figure 4.5 shows the architecture of an ASP.NET Web application. If you compare
Figure 4.4 to Figure 4.5, you can see the underlying differences between the two
technologies, and where you need to focus your upgrade efforts.

Web Browser

Web Server Web Forms

UI Tier Content

ASP.NET Application Server

Internet Run-Time
Business
Information Services
Logic Tier
Services
Web Forms Business Logic
Assembly Components

Data Tier

Data Access
Class (ADO.NET)
Database

Figure 4.5
ASP.NET Web application architecture

In a transition from ASP to ASP.NET, most of the architecture changes occur in the
components to be deployed on the Web server. The Web document model is com-
pletely changed. In ASP.NET, Web pages are built as Web forms, which have sepa-
rate files for document content and document presentation logic and behavior.
Therefore, the business logic and user interface aspects of Web pages are separate. In
this model, the Web form content box is included in the UI tier, and the Web form
executable code (Web form assembly) is included in the business logic tier. The
ASP.NET run-time component provides additional services, including Web security,
caching, and other performance features.
 Chapter 4: Common Application Types 121

Coexistence
ASP and ASP.NET can coexist on the same Web server; however, they are executed
as different, non-communicating processes.
A Web application within a site can contain both ASP.NET pages and ASP pages.
This offers some advantages if you need to move a large, functionally disjointed and
rapidly changing site to ASP.NET one piece at a time. You can upgrade different
sections of the application that do not depend on each other to ASP.NET, and they
can coexist with the rest of the application. If you are transitioning to ASP.NET as a
long-term strategy, you should use this opportunity to make as many architectural
and design improvements as you can. For more information about upgrading to
ASP, see “Migrating to ASP.NET: Key Considerations” on MSDN.
Because the same Web server can access both ASP and ASP.NET pages, you do not
need to upgrade your existing ASP pages to ASP.NET – compatible pages. However,
there are many advantages to doing so. Some of the biggest advantages include the
following:
● Increased performance. Independent tests have shown that ASP.NET applica-
tions can handle two to three times the requests per second as classic ASP appli-
cations. For more details about performance improvements, see Chapter 1,
“Introduction.”
● Increased stability. The ASP.NET runtime closely monitors and manages pro-
cesses. If a process malfunctions (for example, if it leaks or deadlocks), ASP.NET
can create a new process to replace it. This helps to keep your application avail-
able to handle requests.
● Increased developer productivity. Features such as server controls and event
handling in ASP.NET can help you to build applications more rapidly and with
fewer lines of code. It is also easier to separate code from HTML content.
For more information about converting to ASP.NET, see “Converting ASP to
ASP.NET” on MSDN.

The ASP to ASP.NET Migration Assistant

Microsoft provides a free tool for automatically converting ASP pages to ASP.NET.
The tool does not automatically convert all of the ASP features, but it can simplify an
upgrade project by automating some of the steps. To download the migration
assistant, see “ASP to ASP.NET Migration Assistant” in the Microsoft ASP.NET
Developer Center on MSDN.
If you are upgrading an enterprise application that uses ASP, you may need to use
two different upgrade assistants. If the application has a business logic tier, user-
defined classes in the data access tier, and additional components that run on an
application server, you should use the Visual Basic Upgrade Wizard. After you
122 Upgrading Visual Basic 6.0 Applications

successfully upgrade these foundation components, you can convert the ASP code
by using the ASP to ASP.NET Migration Assistant.
For a detailed discussion of the ASP to ASP.NET Migration Assistant, see Appendix
C, “Introduction to Upgrading ASP.”

Porting the ASP Application to ASP.NET

When you upgrade an ASP application to ASP.NET, you must decide how much
time you want to spend incorporating the features of ASP.NET into the existing ASP
application. You can approach this work in one of two ways:
● You can run the migration assistant on the ASP pages, and then apply manual
changes.
● You can re-architect the application and use many of the features of .NET, includ-
ing ASP.NET Web controls, ADO.NET, and the .NET Framework classes.
Although the latter option will make your ASP.NET pages more readable, maintain-
able, and feature-rich, it will also require more time and effort to complete the
upgrade.

Key Considerations
When you upgrade existing ASP pages to ASP.NET pages, you should also be aware
of the following:
● Core API changes. The core ASP APIs have a few intrinsic objects (Request,
Response, Server, and so on) and their associated methods. With the exception of
a few simple changes, these APIs continue to function correctly under ASP.NET.
● Structural changes. Structural changes are those that affect the layout and coding
style of ASP pages. You need to be aware of several of these to ensure that your
code will work in ASP.NET.
● Visual Basic language changes. There are some changes between VB Script and
Visual Basic .NET script that you should prepare for before you upgrade your
application.
● COM-related changes. COM has not been changed at all. However, you need to
understand how COM objects behave when you use them with ASP.NET.
● Application configuration changes. In ASP, all Web application configuration
information is stored in the system registry and the IIS metabase, while in
ASP.NET each applications has it own Web.config file.
● State management issues. If your application uses the Session or Application
intrinsic object to store state information, you can continue to use these in
ASP.NET without any problems. As an added benefit, ASP.NET provides addi-
tional options for your state storage location.
 Chapter 4: Common Application Types 123

● Base class libraries. The base class libraries (BCL) provide a set of fundamental
building blocks that you can use in any application you develop, whether your
application is an ASP.NET application, a Windows Forms application, or a Web
service. You can significantly improve your application by using the BCL.
For information about each of these concerns, see Appendix C, “Introduction to
Upgrading ASP” and “Migrating to ASP.NET: Key Considerations” on MSDN.
The deployment of an upgraded Web application requires the installation of a client
and one or more server computers. All necessary client-side ActiveX components
must be installed on the client. The server must be set up with the complete set of
server controls, component libraries, and data providers.

Application Components
Microsoft developed the component object model (COM) to allow interaction
between applications and to provide a platform for code reuse.
You can create the following types of COM components with Visual Basic 6.0:
● ActiveX code libraries. You can compile these components as COM executable
programs or as DLLs. These libraries include classes that you use by creating
instances in the client application. In Visual Basic 6.0, the project templates you
use to create these COM components are referred to as ActiveX executables and
ActiveX DLLs.
● ActiveX controls. These controls are standard interface elements that allow you
to rapidly assemble reusable forms and dialog boxes.
● ActiveX documents. ActiveX documents are COM components that must be
hosted and activated within a document container. This technology permits
generic shell applications, such as Internet Explorer, to host different types of
documents.
This section provides general information that you can use when you upgrade any
type of supported application component.

Native DLLs and Assemblies

In Visual Basic 6.0, application components are compiled as DLLs that contain
executable code to be used by client applications. These libraries are deployed as
files that have .dll or .exe file name extensions and require the library information to
be registered in the system registry before client applications can access the library
elements.
124 Upgrading Visual Basic 6.0 Applications

An assembly is the primary building block of a .NET Framework – based applica-

tion. It is a component library that is built, versioned, and deployed as a single
implementation unit. Every assembly contains a manifest that describes that assem-
bly. The manifest contains library metadata that maintains the following information:
● The assembly name, version, culture, and digital signature (if the assembly is to
be shared across applications).
● The names of the files that the assembly is built with.

● The names of resources used in the assembly, including information about which
resources are exported from the assembly.
● Compile-time dependencies on other assemblies.

● Permissions required for the assembly.

The .NET common language runtime (CLR) uses this information to resolve refer-
ences, enforce version binding policy, and validate the integrity of loaded assem-
blies. By using the assembly manifest, the CLR eliminates the need to register .NET
components in the system registry before a client application can use them, and
therefore simplifies application deployment and reduces versioning problems. Most
end users and developers are familiar with versioning and deployment issues that
can occur in component-based systems. Many of these issues are related to the
registry entries that are necessary to activate a COM class. The use of assemblies in
the .NET Framework solves a high percentage of these deployment problems.
Assemblies facilitate zero-impact application installation, and they simplify
uninstalling and replicating applications.

Versioning Problems
Currently two versioning problems occur with Win32 applications:
● Versioning rules cannot be expressed for pieces of an application and enforced by
the operating system. The current approach relies on backward compatibility,
which is often difficult to guarantee.
● There is no way to maintain consistency between sets of components that were
built together and the set that is present at run time.
These versioning problems combine to create DLL conflicts, where installing one
application can inadvertently break an existing application because a certain soft-
ware component or DLL was installed that was not fully backward compatible with
a previous version. After this problem occurs, there is no support in the system for
diagnosing and fixing the problem.
 Chapter 4: Common Application Types 125

The Assembly Solution

To solve versioning problems, as well as other problems that lead to DLL conflicts,
the .NET CLR provides assemblies as a means to achieve the following goals:
● Enable developers to specify version rules between different software
components.
● Provide the infrastructure to enforce versioning rules.

● Provide the infrastructure to allow multiple versions of a component to be run

simultaneously (this is called side-by-side execution).

Interoperability Between .NET and COM

When you upgrade application components from Visual Basic 6.0 to Visual Basic
.NET, you should take into consideration the interoperability capabilities of the
.NET CLR. For example, you can upgrade a third-party component through differ-
ent mechanisms, including interoperability wrappers, upgrading to .NET Frame-
work components, and upgrading to third-party components designed for Visual
Basic .NET. You should select the appropriate option for your application by consid-
ering the effort required, the expected results, the available resources, your future
application development plans, and other factors.
Interoperability wrappers allow you to access COM components from a .NET
programming language. (COM clients cannot access .NET assemblies directly.) A
Visual Basic 6.0 application can access a combination of converted components and
wrapped components. For example, you can create interoperability wrappers for
your COM components test them in Visual Basic .NET. If the wrapped component
works as expected, it can be accessed through the wrapper or you can upgrade it to
.NET.

To create a COM wrapper
1. Use the Regsvr32 tool (Regsvr32.exe) to register the original COM component on
the target computer.
2. Use the Type Library Importer utility (Tlbimp.exe) to create an interoperability
wrapper.
3. If the component is an ActiveX control, generate a Windows Forms ActiveX
control importer by using the Windows ActiveX Control Importer utility
(Aximp.exe).
For more information about creating COM wrappers and for example code, see
Chapter 14, “Interop Between Visual Basic 6.0 and Visual Basic .NET.”
Figure 4.6 on the next page shows how interoperability is set up and how a .NET
client uses it.
126 Upgrading Visual Basic 6.0 Applications

Common Language Runtime

COM Type Tlbimp.exe Metadata in

Library an Assembly

.NET Interop
Marshaling Service

Method
Calls
COM Object RCW .NET Client

Figure 4.6
Accessing a COM component through interoperability

In Figure 4.6, the Type Library Importer utility (Tlbimp.exe) analyzes the COM
library, and converts the type definitions to equivalent definitions in an assembly
that contains metadata which corresponds to the original COM library. The CLR.
creates a runtime callable wrapper (RCW) for each COM object. The main function
of the RCW is to marshal the calls between the .NET client and the COM object. This
marshaling includes the conversion of data types so that the two technologies can
communicate. The .NET client can access the COM library by using the RCW as an
intermediary.
The interoperability wrapper created is a .NET assembly that wraps the COM
component. The assembly must be registered in the global assembly cache if it will
be shared by different applications. There are several reasons why you might want
to put an assembly in the global assembly cache:
● The global assembly cache provides a central location for shared assemblies. If
an assembly will be used by multiple applications, it should be put in the global
assembly cache.
● The global assembly cache can improve file security. Administrators often
protect the WINNT directory by using an access control list (ACL) to control
write and execute access. Because the global assembly cache is installed in the
WINNT directory, it inherits that directory’s ACL.
● The global assembly cache allows side-by-side versioning. The global assembly
cache can maintain multiple copies of assemblies with the same name, but differ-
ent version information.
● The global assembly cache is the primary CLR search location. The common
language runtime checks the global assembly cache for an assembly that matches
the assembly request before probing or using the code base information in a
configuration file.
 Chapter 4: Common Application Types 127

For more information about wrappers, see “Customizing Standard Wrappers” in the
.NET Framework Developer’s Guide on MSDN.
Despite the advantages, you should share assemblies by installing them in the global
assembly cache only when necessary. As a general guideline, keep assembly depen-
dencies private and place assemblies in the application directory unless sharing an
assembly is explicitly required. In addition, you do not have to install assemblies in
the global assembly cache to make them accessible to COM Interop or unmanaged
code.
Note that there are situations where you should not install an assembly into the
global assembly cache. For example, if you place one of the assemblies in an applica-
tion in the global assembly cache, you can no longer replicate or install the applica-
tion by using XCOPY installation. In this case, you must place all of the application’s
assemblies into the global assembly cache. For more information about working
with assemblies, see “Working with Assemblies and the Global Assembly Cache” in
the .NET Framework Developer’s Guide on MSDN.
There are two ways to install an assembly in the global assembly cache:
● Use Microsoft Windows Installer 2.0. This is the recommended and the most
common way to add assemblies to the global assembly cache.
● Use the Global Assembly Cache tool (Gacutil.exe). This approach is recom-
mended for development purposes. However, you should not use this approach
to add production assemblies to the global assembly cache.

Reusable Libraries
Visual Basic 6.0 components can run in any one of three places:
● In the same address space as the client (in-process).

● On the same computer (out-of-process).

● On a remote computer (out-of-process).

An in-process component can be implemented as a DLL or as an ActiveX control.

Each client application that uses the component starts a new instance of the compo-
nent.
Out-of-process components are implemented as executable files and run in their
own process space on a local or remote computer. Communication between the
client and an out-of-process component requires that parameters and return values
be marshaled across process boundaries. A single instance of an out-of-process
component can service many clients, share global data, and provide insulation
between client applications. This kind of component can be implemented by means
of DCOM or COM+. For information about upgrading this type of component, see
the “Distributed Applications” section later in this chapter.
128 Upgrading Visual Basic 6.0 Applications

The rest of this section explains how to upgrade of ActiveX code components. These
components correspond to the Visual Basic 6.0 ActiveX DLL project template.
In most cases, code components have no user interface. Instead, they consist of
libraries of classes that allow client applications to instantiate objects based on those
classes. In earlier documentation, code components were referred to as OLE Auto-
mation servers.
The equivalent .NET project for an ActiveX DLL is a .NET class library. The Visual
Basic Upgrade Wizard automatically upgrades most of the code inside the original
ActiveX DLL project and generates the corresponding Visual Basic .NET project
type. After an automated upgrade, you will have language issues that you must
correct manually. For an explanation on unsupported language features, see Chap-
ters 7 – 11.
Visual Basic .NET class libraries contain reusable classes or components that can be
shared with other projects. This project type is considered to be windowless and will
not contain a Windows Form class; this restriction may be an obstacle for you if you
used the Visual Basic 6.0 code component library to provide standard libraries of
modal and modeless dialogs. However, the Visual Basic Upgrade Wizard upgrades
form objects and compiles them inside the component. If it is necessary to allow
other applications to use these form classes, you must change the corresponding
access level from Friend to Public.
To further improve your application, you should move all visual classes to another
component. This will separate the presentation and business tiers that exist in a
single component and produce a more modular architecture.

ActiveX Controls
An ActiveX control is a COM component with user interface elements. ActiveX
controls were previously known as OLE controls or OCX controls. These controls
can be used in the same way as any of the standard built-in controls, and provide an
extension to the Visual Basic 6.0 toolbox. ActiveX controls created in Visual Basic can
be used in different container applications, including Visual Basic applications,
Microsoft Office documents, and Web pages accessed through a Web browser like
Microsoft Internet Explorer.
An application can provide ActiveX controls with other Visual Basic 6.0 components,
or it can access and use third-party ActiveX controls. If the ActiveX controls are
components in your application, you can use the Visual Basic Upgrade Wizard to
upgrade the source code for the control. If the ActiveX control source code is not
available, you can replace the control with other upgraded components or you can
use interoperability to access the control, as described previously in this chapter. The
remainder of this section explains how to upgrade user-defined ActiveX controls.
 Chapter 4: Common Application Types 129

In Visual Basic 6.0, an ActiveX control is always composed of a UserControl object

and any controls (known as constituent controls) that are placed on it. The equivalent
.NET component for an ActiveX control is a .NET UserControl. When you use the
Visual Basic Upgrade Wizard to upgrade an ActiveX control, a class library project is
created inside the target solution. The project contains a UserControl module that
encloses a class declaration which is equivalent to the original Visual Basic 6.0
UserControl. The new class inherits from System.Windows.Forms.UserControl,
which in turn inherits from ContainerControl and contains all of the standard
positioning and mnemonic-handling code that is necessary in a base for creating
new controls.
The wizard automatically upgrades aspects of the Visual Basic 6.0 UserControls to
.NET UserControls, as follows:
● Constituent visual elements. The wizard updates basic elements of the
UserControl and all corresponding design time properties.
● Internal logic. The wizard updates code that controls the component behavior
and the interaction with clients.
● Event handlers. The wizard converts event handler declarations included in
component clients in accordance with the new .NET UserControl events. Note
that only those component clients upgraded during the same upgrade process as
the original UserControl are automatically updated to accommodate changes
caused by the upgrade of the UserControl. If other user applications use a com-
piled version of the ActiveX control, their access will be upgraded as access to a
wrapped ActiveX control. You can improve this last upgrade by including all
necessary components in the same upgrade project so that the wizard can process
them at the same time.
The Visual Basic Upgrade Wizard does not support Visual Basic 6.0 project groups. If
ActiveX controls are included in a Visual Basic 6.0 project group, you should use the
following strategy to upgrade the project package:
1. Obtain a list of the dependencies between the projects that compose the applica-
tion.
2. Determine which projects do not depend on other projects, and upgrade them as
individual components.
3. For each project that has a dependency on another project, replicate all needed
objects into the dependent project. This will allow the dependent project to
process all of the transformations that occurred in other project objects. Upgrade
the dependent projects.
4. When all projects are upgraded, eliminate redundant objects and set the proper
dependencies between projects. These should be the same as in the original
project group.
130 Upgrading Visual Basic 6.0 Applications

When you upgrade a user-defined ActiveX control to Visual Basic .NET, you can
include it in the control toolbox, just as you would any pre-defined control. User-
defined ActiveX controls appear in the User Control Tab of the toolbox, while the
predefined controls appear in the General tab of the toolbox. You can place in-
stances of the upgraded control on .NET Windows Forms, and you can set the
control’s design time properties by using the .NET form editor.
You can use property pages to define a custom interface for setting properties of an
ActiveX control; this is an extension of the Properties window. However, the Visual
Basic Upgrade Wizard does not support this feature, and you must reimplement the
property page user interface, synchronize the property values and the state of the
control, and associate the control properties and dialog box fields. For more infor-
mation, see Chapter 9, “Upgrading Visual Basic 6.0 Forms Features.”

ActiveX Controls Embedded in Web Pages

You can insert ActiveX controls in Web pages by using the <Object> HTML tag. This
tag receives a ClassId parameter that corresponds to the ActiveX component identi-
fier. The identifier is required so that the component can be registered on the client
computer and instantiated and displayed correctly by the Web browser.
You can achieve functional equivalence for an upgraded Web application by leaving
embedded controls inside Object tags. If the original ASP application included
server-side components, you can wrap these components by using the
interoperability feature.
Although you can access embedded controls programmatically, you may discover
that the controls affect the quality of the application you are upgrading, as follows:
● You must use additional languages — such as VBScript, JScript®, JavaScript, and
DHTML — to achieve dynamic behavior.
● Your need more steps to deploy the application, and additional files need to be
downloaded.
● The component will have fewer resources — such as application servers and
database resources — available to it.
ASP.NET provides a different model for Web development, which includes control
types that are specifically designed to be used in a Web environment. These control
types include:
● HTML server controls. These are HTML elements exposed to the server so you
can program them. HTML server controls expose an object model that maps very
closely to the HTML elements that they render.
● Web server controls. These are controls with more built-in features than HTML
server controls. Web server controls include form-type controls, such as buttons
and text boxes, and special-purpose controls, such as a calendar. Web server
 Chapter 4: Common Application Types 131

controls are more abstract than HTML server controls in that their object model
does not necessarily reflect HTML syntax.
● Validation controls. These are controls that incorporate logic to allow you to test
a user’s input. You can attach these controls to an input control to test what the
user enters for that input control. Validation controls are provided to allow you to
check for a required field, to test against a specific value or pattern of characters,
to verify that a value lies within a range, and so on.
● User controls. These are controls that you create as Web Forms pages. You can
insert Web Forms user controls in other Web Forms pages, which is an easy way
to create menus, toolbars, and other reusable elements.
These control types provide reimplementation alternatives for ActiveX controls
embedded in Web pages. Depending on the functionality of the original ActiveX
control, you may find it convenient and appropriate to implement it as a Web
control. For example, if an application has an ActiveX control that communicates
with different servers to obtain and process data, it is generally more efficient to
create a new Web server control that executes the communication and heavy pro-
cessing on the server and renders visual elements to the Web client.
The ASP to ASP.NET Migration Assistant tool treats ActiveX controls embedded in
Web pages as HTML tags and keeps them in the target ASP.NET files. Therefore,
these elements of the Web page are not automatically transformed. You must manu-
ally complete any further upgrades.
You should wait until after you complete the initial (automatic) upgrade before you
re-implement any components. After you reach functional equivalence, you can
complete any re-implement as part of the upgraded application advancement. For
more information about this process, see Chapter 17, “Introduction to Application
Advancement” or “Introduction to ASP.NET Server Controls” on MSDN.

ActiveX Documents
ActiveX documents are COM components that must be hosted and activated within
a document container. They provide the application functionality; they also provide
the ability to persist and distribute copies of the data intrinsic to the application.
These components can be used on HTML pages or as alternatives to HTML pages,
and they can be deployed so that users can navigate transparently between ActiveX
documents and other pages in the application or Web site.
The .NET Framework does not have a component type equivalent to ActiveX docu-
ments. Therefore, you must redesign and/or re-implement ActiveX documents by
using a .NET Framework – based component.
The following list presents important ActiveX document features that you should
consider when you upgrade to Visual Basic .NET:3
132 Upgrading Visual Basic 6.0 Applications

● Automatic downloading of components over the Internet. You can create a link
to the ActiveX document so that the browser can find and download all compo-
nents that are needed to run the component.
● Hyperlinking of objects. In a hyperlink-aware container, you can use the proper-
ties and methods of the Visual Basic Hyperlink object to jump to an URL or
navigate through the history list.
● Interaction with the container window. You can use ActiveX documents to
access additional pieces of the container window; for example, the component
menus can be merged with the browser menus.
● Storing of data. When you deploy an ActiveX document in Internet Explorer, you
can store data through the PropertyBag object.
You can use the upgrade wizard to partially upgrade ActiveX documents if you
move the ActiveX document source code to another module type that the upgrade
wizard supports. For example, you can copy the source code and the controls
contained in the ActiveX document into a new Visual Basic 6.0 UserControl. A
considerable portion of the UserControl source code will be automatically up-
graded; however, all unsupported features in the original ActiveX document source
code will not be upgraded and must be re-implemented.
You can re-implement ActiveX document components by using Visual Basic .NET
UserControls or XML Web forms, which can be hosted in different types of contain-
ers. You will lose some of the original functionality unless you redesign and imple-
ment it in the new platform. You can implement most of this functionality by using
the services provided by the .NET Framework, such as serialization interfaces and
the ability to run at the server or at the client depending on your chosen design.

Distributed Applications
A distributed application is one in which some of the application components are
executed on remote computers and there is interaction between local and remote
components. To have an effective interaction between these components, you must
use numerous basic services, such as communication protocols, security, and re-
source locator services. A distributed application offers important advantages for
the enterprise environment, including improved scalability, reliability and failure
tolerance.
The following sections describe some of the things you should consider when you
upgrade components of distributed applications.

DCOM Applications
The distributed component object model (DCOM) extends the component object
model (COM) to support communication between objects on different computers on
 Chapter 4: Common Application Types 133

a local area network (LAN), a wide area network (WAN), or even the Internet. With
DCOM, your application can be distributed to any location that makes sense to your
users and to the application.
DCOM is an extension of COM; therefore, you can use your existing COM-based
applications, components, tools, and knowledge when you move to DCOM. DCOM
handles low-level details of network protocols.
Remoting is considered to be the .NET equivalent of DCOM. It is a framework
designed to simplify communication between objects. Remoting supports communi-
cation between objects that exist in different application domains and have different
contexts, regardless of whether or not the objects are on the same computer or even
the same application domain.
The remoting framework is built into the common language runtime and can be
used to build sophisticated distributed applications. Some of the features provided
by .NET remoting are:4
● Proxy objects. .NET remoting creates a proxy object when a client activates a
remote object. The proxy object acts as a representative of the remote object. All
calls made to the proxy are forwarded to the correct remote object instance.
● Object passing. The remoting framework provides mechanisms for passing
objects between applications. These mechanisms handle the marshaling details.
● Activation models. .NET remoting provides more than one way to activate
remote objects.
● Stateless and stateful objects. .NET remoting provides many ways to achieve
state management and to manage stateless objects.
● Channels and serialization. .NET remoting provides a transport mechanism
called .NET channel services to transport messages between applications and
application domains. .NET provides serialization (it can transport objects across
byte streams) and uses formatters to encode and decode these byte streams.
● Lease-based lifetime. .NET remoting allows the application to control the length
of time that a client can remain connected to a remote object by using a lease.
When the lease expires, the object is automatically disconnected. .NET remoting
also provides methods to extend a lease when needed.
● Hosting objects in IIS. .NET remoting objects can be hosted in any .NET-based
executable or managed service, but they can also be hosted in IIS. This allows
remoting objects to be exposed as Web services.

You can upgrade a Visual Basic 6.0 application that uses distributed component
technologies to Visual Basic .NET in two different ways:
● By using new COM classes

● By using .NET remoting

134 Upgrading Visual Basic 6.0 Applications

The following sections describe the advantages and disadvantages of each approach.

Using COM to Upgrade a Distributed Application

For the first option, you must create additional COM classes to serve as proxies
that communicate with the DCOM infrastructure. Managed code can access these
new classes by using COM interoperability. This alternative has the following
advantages:
● It provides an easy and fast upgrade implementation. The new COM wrapper
classes only need to provide a communication link between the DCOM infra-
structure and Visual Basic .NET.
● It provides upgrade path flexibility. Because this solution does not need exten-
sive resources, you can use multiple stages to implement it if your application is
complex.
● It allows early testing of component interaction. You can schedule early testing
of these components in parallel with other upgrade tasks.
This is a mixed solution, where managed code interacts with unmanaged compo-
nents and operating system services. The main disadvantages of this approach are:
● Additional communication requirements. The new intermediary classes and
interoperability wrappers consume more communication and processing re-
sources.
● Adoption of new technologies is limited. Because of the dependency on legacy
technologies, adoption of new features and services offered by the .NET Frame-
work are limited.
● Reduced maintainability. The new classes increase the complexity of the
application.

Using .NET Remoting to Upgrade a Distributed Application

Another upgrade option is reimplement the application and use .NET remoting
services. You can upgrade the application logic by using the Visual Basic Upgrade
Wizard. You will then need to use .NET remoting services to re-implement the code
that uses DCOM. To enable remoting, the distributed objects must derive from the
MarshalByRefObject class. Note that this is a built-in feature of COM+ classes,
which inherit from ServicedComponent, which in turn inherits from the
MarshalByRefObject class.

MTS and COM+ Applications

After you create and deploy a business logic COM component in a single computer
environment, you may need to separate the component from its original run-time
environment and place it in a different administrative and execution platform. In
this way, you can achieve a multi-tier architecture for your application.
 Chapter 4: Common Application Types 135

There are several reasons why you may need to perform for this type of separation,
including scalability, manageability, accountability, and performance. Microsoft
provides two main technologies to create this type of architecture: Microsoft Trans-
action Server (MTS) and COM+.
MTS provides transaction services, which facilitate the transition from single-user to
multi-user architectures and provide application infrastructure and administrative
support for building scalable and robust enterprise applications. Although transac-
tion management is an integral part of many applications, MTS also provides useful
services for applications that do not use transactions at all.
Components that encapsulate application logic can run under the control of MTS
and are invoked by presentation services from a variety of clients, including:5
● Traditional applications that were developed in Visual Basic or other languages
that support COM.
● Web browsers.

● Active Server Pages scripts that run within IIS.

You can use Visual Basic 6.0 with MTS to build n-tier applications. To do this, you
develop COM DLL components that run on middle-tiered servers under the control
of MTS. When clients call these COM DLLs, Windows automatically routes the
requests to MTS.
Other services provided by MTS that are relevant to upgrade efforts include:
● Component transactions.

● Object brokering.

● Resource pooling.

● Just-in-time activation.

● Administration.

Upgrade Strategy
One upgrade strategy that you can use is to provide proxy COM classes that can be
accessed through interoperability, as explained in the “DCOM Applications” section
earlier in this chapter. However, this approach may not be adequate in all situations,
and you may need to re-implement MTS and COM+ services.
The .NET Framework contains classes that offer similar functionality or provide an
interface to mechanisms used by COM+. These classes are included in the
System.EnterpriseServices namespace, which provides an infrastructure for enter-
prise applications that allows .NET objects to access COM+ services. These classes
make .NET Framework objects useful for enterprise applications.
The core services employed by MTS and COM+ applications are encapsulated in the
COM+ services type library (COMSVCS.DLL).
136 Upgrading Visual Basic 6.0 Applications

Note: Most of the upgrade effort for components discussed in this section will be automatically
performed by the Visual Studio 2005 version of the Visual Basic Upgrade Wizard.6

General Considerations for COM+ Visual Basic 6.0 Projects

You should understand the information in this section so that you can correctly
prepare and set up the .NET application that will be the target of a COM+
application.
The System.EnterpriseServices namespace contains all of the classes necessary to
interact with COM+. To enable COM+, you must include a reference to this
namespace in the target Visual Basic .NET project.
You need to use the Strong Name tool (Sn.exe, which is included with the .NET
Framework) to generate a key file, and then add this file and an assembly attributes
file that includes the AssemblyKeyFile attribute to the project file. Give the project
file the same name as the original Visual Basic 6.0 project, and store it in the upgrade
output folder.
You should include documentation or utilities to help users register assemblies with
.NET Services Installation Tool (Regsvcs.exe) so they can deploy the upgraded
components. You can use the registration helper API
(System.EnterpriseServices.RegistrationHelper.InstallAssembly) for this purpose.
Table 4.3 shows the components and services that provide the core MTS and COM+
functionality and their corresponding equivalents in the .NET Framework. For
detailed information about upgrading each component, see Chapter 15, “Upgrading
MTS and COM+ Applications.”

Note: Each .NET component or namespace shown in the table should be prefixed with
System.EnterpriseServices; for example, the full name for CompensatingResourceManager is
System.EnterpriseServices.CompensatingResourceManager.

Table 4.3: MTS and COM+ Components .NET Equivalents

COM+ Component/Service .NET Equivalent
Compensating resource Components in the CompensatingResourceManager
manager namespace
Object pooling ServicedComponent
Application security SharedPropertyManager, SharedPropertyGroup, SharedProperty
Object constructor strings ServicedComponent
Transactions The functionality can be achieved with the class
ServicedComponent and an appropriate mapping for the
MTSTransactionMode property, as specified with a
TransactionOption enumeration value.
 Chapter 4: Common Application Types 137

Unsupported Functionality
The COM+ services type library is used with Visual Basic and other languages
capable of building COM applications. Some members included in this library
cannot be used in Visual Basic 6.0 because they were specifically created for use with
Visual C++. An example of such a class is the CServiceConfig class. These classes
may have .NET Framework mappings, but they are unsupported by Visual Basic 6.0.
Similarly, Visual Basic 6.0 supports members that do not have semantic equivalents
in the .NET Framework. These unsupported components include functionality in the
following areas: security, context management, events management, resource loca-
tor, service configuration, and log management.
For more information about COM+ upgrades and unsupported functionality, see
Chapter 15, “Upgrading MTS and COM+ Applications.”

Summary
Understanding the possible application types that you may need to upgrade will
help you to better understand how each type should be upgraded. Each type has
features that are easy to upgrade and features that are hard to upgrade. Being aware
of potential problem areas before you begin can lessen the impact those problem
areas will have on your upgrade process.
With an understanding of the different categories of applications, you can now begin
learning the general upgrade processes and practices that are applicable to all
upgrade projects. The next chapter will give you the details you need to understand
the Visual Basic 6.0 to Visual Basic .NET upgrade process.

More Information
For more information about upgrading to ASP see “Migrating to ASP.NET: Key
Considerations” on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html
/aspnetmigrissues.asp.
For a free tool to automatically convert ASP pages to ASP.NET, see “ASP to ASP.NET
Migration Assistant” in the Microsoft ASP.NET Developer Center on MSDN:
http://msdn.microsoft.com/asp.net/migration/aspmig/aspmigasst/default.aspx.
For more information about wrappers, see “Customizing Standard Wrappers” in the
.NET Framework Developer’s Guide on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html
/cpconcustomizingstandardwrappers.asp.
138 Upgrading Visual Basic 6.0 Applications

For more information about working with assemblies, see “Working with Assem-
blies and the Global Assembly Cache” in the .NET Framework Developer’s Guide on
MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html
/cpconworkingwithassembliesglobalassemblycache.asp.
For more information about ASP.NET server controls, see “Introduction to ASP.NET
Server Controls” on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html
/vbconintroductiontowebformscontrols.asp.

Footnotes
1. Upgrading Microsoft Visual Basic 6.0 to Visual Basic .NET e-Book. Chapter 3: Upgrading options \
Selecting projects to upgrade
2. Upgrading Microsoft Visual Basic 6.0 to Visual Basic .NET e-Book. Chapter 11: Resolving issues with
language \ Making Your Code Thread-Safe
3. Desktop Applications with Microsoft Visual Basic 6.0, MCSD Training Kit.
4. Upgrading Microsoft Visual Basic 6.0 to Visual Basic .NET e-Book. Chapter 21: Upgrading Distributed
Applications \ Remoting
5. Web Applications with Microsoft Visual InterDev 6.0, MCSD Training Kit.
6. Visual Basic Upgrade Wizard Whidbey version specification, COM+ Services Type Library Migration
5
The Visual Basic Upgrade Process
This chapter provides an in-depth explanation of the technical aspects of the Micro-
soft Visual Basic 6.0 to Visual Basic .NET upgrade process. It explains each step of
the process, from initial preparation to final deployment of the application. It also
describes how to use the Visual Basic Upgrade Wizard to automate much of the
upgrade. It also discusses tasks you will have to manually perform and provides
general recommendations to achieve a successful upgrade.

Procedure Overview
The steps involved in an upgrade project can be divided in the following groups:
1. Application preparation
2. Application upgrade
3. Application testing and debugging
These task groups require specialized skills and experience. The tasks included in
each group can be executed with a certain level of parallelism, depending on the
availability and specialization of resources needed. The task groups do not define a
linear order of execution; there may be groups of tasks that are simultaneously
executed for different parts of the application.
The upgrade procedure, including inputs and outputs where applicable, is summa-
rized here:
1. Application preparation. This includes:
a. Development environment preparation.
Input: Software development installers, third party component installers
Output: A fully configured application development environment that corre-
sponds to the application to be upgraded
b. Upgrade tool preparation.
140 Upgrading Visual Basic 6.0 Applications

Input: Upgrade wizard installer, installers for the analysis tools

Output: A fully configured system where the original application can run
c. Obtaining the application resource inventory.
Input: Available information about the specifications and design of the origi-
nal application
Output: Catalog of documentation useful for upgrade purposes
d. Compilation verification.
Input: The original Visual Basic 6.0 application in a correctly configured
system
Output: System where the original application can be compiled, debugged,
and executed
e. Project upgrade order definition.
Input: Original source code
Output: An analysis of the application component dependencies based on
analysis tools that can be used to plan the upgrade order of the different
components
f. Reviewing the upgrade wizard report.
Input: Upgrade wizard report for a partial test upgrade of the original
application.
Output: Detection of computing resource problems and estimation of upgrade
effort.
2. Application upgrade. This includes:
a. Execution of the Visual Basic Upgrade Wizard.
Input: Original Visual Basic 6.0 source code and upgrade system
Output: Initial upgraded application code base in Visual Basic .NET; this code
base will likely contain upgrade issues that will later need to be addressed
b. Verifying the progress of the upgrade.
This is a control step that verifies the correct execution of the upgrade wizard.
c. Upgrade wizard execution error correction.
This is a corrective step that can be applied when the upgrade wizard execu-
tion experiences problems.
d. Completing the upgrade with manual changes.
Input: Initial upgraded application code base in Visual Basic .NET
Output: An upgraded Visual Basic .NET application that can be compiled
 Chapter 5: The Visual Basic Upgrade Process 141

3. Testing and debugging the upgraded application. This includes:

a. Original test cases execution.
Input: An upgraded Visual Basic .NET application that can be compiled
Output: List of broken test cases and run-time bugs detected in the application
b. Fixing run-time errors.
Input: An upgraded Visual Basic .NET application that can be compiled
Output: An upgraded Visual Basic .NET application that can be correctly run
The remainder of this chapter details each of these steps.

Application Preparation
The Visual Basic Upgrade Wizard is a tool that can automatically perform complex
tasks and help ease the upgrade process. The results obtained with this tool are
affected by the preparation applied to the original source code and how much of this
application is amenable for automated upgrade to Visual Basic .NET. This section
provides guidelines for the preparation of your application and the processing
environment to maximize the work done by this tool and have a successful upgrade.
Appropriate preparation of your application will save a considerable amount of
work in different areas, including management, development, and testing. Prepara-
tion for upgrade processes is especially important because it involves many aspects
over a long period of time. Errors in the initial stages of the process can easily
propagate and consume an extended amount of work. Additionally, a difficulty
discovered after the automated upgrade may require a part of the application to be
upgraded again, possibly producing delays in the other stages of the upgrade.
It is recommended that you begin by first preparing the upgrade development
environment. It is likely that the existing development environment is already
properly set up for building the original source code, so this preparation is relatively
inexpensive. Even when problems are identified, it is typically a matter of reinstall-
ing missing components, and correcting these types of errors should not be problem-
atic. Investing the time to correctly prepare the development environment and
correcting issues like missing components before you begin will save considerable
time and effort later in the upgrade process.
After the upgrade development environment is prepared, work can be concentrated
on preparing the source code itself. This includes examining the source code, verify-
ing the compilation, and identifying common upgrade issues.
As with any complex procedure, it is beneficial to document all the important steps
in an upgrade procedure log, including the products of each upgrade step, compo-
nent dependency relationships, and upgrade order. This document will provide you
142 Upgrading Visual Basic 6.0 Applications

with a clear view of the process, allowing you to plan and measure the effort re-
quired for the future steps of the upgrade process. It will also be useful as a base for
future upgrade projects. Figure 5.1 illustrates a sample upgrade procedure log.

Figure 5.1
Sample upgrade procedure log

The preparation steps are detailed in the following sections.

Development Environment Preparation

Careful preparation of your development environment before beginning an upgrade
project will help to ensure success. It is recommended that you execute the upgrade
process on a computer with the same development environment that was used to
create the original application. This will facilitate the analysis of the original applica-
tion and will allow for the execution of the initial preparation tests.
Typically, computers used for application development have physical resources that
are extremely useful, if not essential, for the execution of the upgrade wizard.
There are two main environment aspect types that affect the upgrade process. The
first aspect type, system resources, affects the speed of the upgrade process. The
second environment aspect type, external dependencies, affects the normal execu-
tion and termination of the upgrade wizard. It will produce exceptions whenever
necessary components are not present on the computer where the upgrade process is
executed.
 Chapter 5: The Visual Basic Upgrade Process 143

System Resources
The upgrade wizard loads all global declarations of the application into memory
and keeps them there throughout the upgrade process; this is necessary to resolve
the types of members that are accessed from other modules. When a file is being
upgraded, it is loaded into memory, and all necessary transformations are applied to
it. Upon completion, the result is written to disk and the information about the
module’s local declarations is deleted from the upgrade wizard data structures.
The upgrade wizard is not an I/O intensive application; however, it makes demand-
ing usage of memory and processor resources for the storage of language structures
and the execution of transformation rules. A Visual Basic 6.0 application with 20,000
lines of code will have a peak memory usage between 160 MB to 200 MB. The
amount of memory available for the upgrade process will dramatically affect its
speed. The minimum memory size recommended for a computer on which the
upgrade wizard will be applied is 512 MB. The amount of memory should grow
according to the size and complexity of the application. Visual Basic 6.0 applications
with more than 100,000 lines of code will require a minimum of 1 GB of memory to
be upgraded. If the size of the application is millions of lines of code, a computer
with 2 to 3 GB of memory should be used. It may also be convenient to separate the
application to upgrade it in more manageable pieces.
With respect to the CPU recommendation, an Intel Pentium 4 class processor or
equivalent can process an average size application in a range of hours, assuming the
system has enough RAM.
The system’s hard drive should have enough free space to store at least three times
the size of the original application. This is necessary to generate all temporary files
and the final result of the upgrade.

External Dependencies
Typical Visual Basic 6.0 applications use third-party components. Some applications
explicitly reference external DLLs through the project settings while others dynami-
cally reference and create objects based on the components currently installed.
The upgrade of these applications requires special attention to be put on the installa-
tion and availability of these external components. All third-party components
referenced by the application to be upgraded must be installed and available. If a
component that is explicitly referenced in the project is not available in the system,
the command-line version of the upgrade tool, Visual Basic Upgrade Tool, will
display the following message and stop the execution:
Exception occurred: Could not load referenced component:
NameOfTheComponent.ocx (8.0.0)
You need to install this component before you upgrade the project.
144 Upgrading Visual Basic 6.0 Applications

It is recommended you install Visual Basic 6.0, with all referenced components,
and ensure the application compiles and runs before upgrading.
Similarly, if the application is upgraded through the use of the wizard version of the
upgrade tool (available in Visual Studio .NET), the upgrade wizard will display the
following message and stop the execution:
Upgrade failed: Exception occurred: Could not load referenced component:
NameOfTheComponent.ocx (2.0.0)
You need to install this component before you upgrade the project.
It is recommended you install Visual Basic 6.0, with all referenced components,
and ensure the application compiles and runs before upgrading.
Additionally, the following information will be shown as part of the project upgrade
log.
<Issue
Type = "Global Error"
Number = "4002"
>Could not load referenced component: NameOfTheComponent.ocx (2.0.0) You
need to install this component before you upgrade the project.It is recommended
you install VB6.0, with all referenced components, and ensure the application
compiles and runs before upgrading.</Issue>

When installing trial versions of third-party components, some of them will display
a license information dialog box each time the component is instantiated. This dialog
box will suspend the execution of the host application, such as the upgrade wizard.
If trial versions are installed for some of the components, it is recommended that
you pay attention to the messages displayed by the upgrade wizard until the pre-
processing phase starts so you can respond to all dialog boxes that are displayed by
trial version components. After the preprocessing phase starts, the upgrade wizard
can be left unattended and will continue the upgrade until the upgraded code base
is obtained.
As part of the application preparation, it is also important to make limited tests on
the upgrade of third-party components that have a complex user interface. Reduced
size applications can be written to instantiate and access the core functionality of
these components. After these applications are written, the upgrade wizard can be
used; then the code it produces can be evaluated. Special attention should be dedi-
cated to design and run time visualization and behavior of the upgraded compo-
nents. In this preliminary component test phase, the interaction between the
component, the interoperability wrapper, and Visual Basic .NET components will
be verified. For more information about interoperability, see Chapter 14, “Interop
Between Visual Basic 6 and Visual Basic .NET.” It may be useful to identify and
isolate problematic elements that will negatively affect the automated upgrade of
 Chapter 5: The Visual Basic Upgrade Process 145

the full application. Most of the reasons for these problems are non-standard inter-
faces or implementations of some components. If one of these components produces
run-time errors during the execution of the upgrade wizard, one possible solution is
to remove the component and upgrade the rest of the application. The functionality
provided by this component can then be implemented again in Visual Basic .NET.

Upgrade Wizard Preparation

Preparation for an upgrade process involves the following three areas that consider
different aspects of the original application:
● Preparation of the upgrade wizard and external aspects of the application. This
area includes the setup of all necessary tools for development and upgrade. For
more information, see the “Development Environment Preparation” and “Third-
Party Components” sections earlier in this chapter.
● Evaluation of the application. In this area of preparation, the application is
evaluated to assess its composition and the possible difficulties that may arise
when the upgrade process has been applied. The effort and cost estimation will
be generated before the actual upgrade. This aspect of preparation is assisted by
various tools, including the Visual Basic 6.0 Assessment Tool. For more informa-
tion about assessment and effort estimations, see Chapter 3, “Assessment and
Analysis.”
● Adjustment of the original application. In this area of preparation, adjustments
are made to the original application to facilitate the upgrade process. These
changes can be made to increase the automatic work done by the upgrade wizard
and to reduce the manual completion tasks that are necessary after the automatic
process. These changes are based on the initial assessment and general advice
that can be obtained from different sources such as documentation and advisor
tools. For more information about application adjustment, see the “Visual Basic
6.0 Assessment Tool” and “Removing Unused Components” sections later in this
chapter.
The preparation of internal aspects of the application is essential because it will
directly affect the quality of the obtained product and the amount of manual effort
required after the automated upgrade. Software tools for the preparation of internal
aspects of the application have proven to be extremely useful to assess the size and
complexity of the application to be upgraded and to assist the developer in the
changes that need to be made. The union of these data provides the foundation for
accurate upgrade effort estimations.
The tools that will be discussed in this section provide different types of information
that can be used for code assessment, effort estimations, and the adjustment of the
original code. These tools extract the application information directly from the
source code by parsing the different application modules. Each has a different
146 Upgrading Visual Basic 6.0 Applications

analysis focus and provides complementary views of the application and the process
of upgrading it. The tools are listed here:
● The Visual Basic 6.0 Upgrade Assessment Tool generates an extensive inventory
of the application; it pays special attention to the features that are difficult to
upgrade.
● The Visual Basic 6.0 Code Advisor recognizes features in the original application
that can be modified to have a smoother transition to Visual Basic .NET.
Although the tools for upgrade preparation make an exhaustive review of the code,
the time required to complete the process is a fraction of the full upgrade process.
This is mainly because the tools analyze the code fragments and identify certain
patterns, but the tools do not apply transformations. These preparation tools are
provided as a way to quickly estimate and improve the results that will be obtained
after the upgrade process is applied.

Visual Basic 6.0 Upgrade Assessment Tool

The Visual Basic 6.0 Upgrade Assessment Tool analyzes Visual Basic 6.0 source code
and generates extensive information about an application. For more information
about the types of information gathered by the tool, see Chapter 3, “Assessment and
Analysis.”
The tool can analyze multiple project files at the same time. This allows a user to
select them individually, by groups, or by searching all .vbp files in a directory and
its subdirectories. The tool has a weights file that can be used to assign a complexity
value to each upgrade issue and generate customizable effort estimation data.
The assessment tool generates different types of reports with application statistics
and upgrade issues that can be used to estimate the upgrade effort. Most, but not all,
of the issues that require manual adjustments are identified. Among the statistics
generated, there are data related to control usage, accesses to class members, and
library occurrences.
An additional source of information that is useful for estimation tasks is the Up-
grade Issues table. This report contains data regarding the usage of functionality
that has proven to be difficult to upgrade. Each issue contained in the table has an
associated complexity level that is a measure of the upgrade difficulty and the
manual work required. Some of the issues that can be detected and included in this
table are COM+ functionality, Visual Basic 6.0 performance features for games, and
ActiveX documents.
For more information about the assessment tool, see Chapter 3, “Assessment and
Analysis.”
 Chapter 5: The Visual Basic Upgrade Process 147

Visual Basic 6.0 Code Advisor

The Visual Basic 6.0 Code Advisor is a Visual Basic 6.0 add-in that can be used to
review the source code of an application. This tool helps the developer to ensure that
the application meets predetermined coding standards. The coding standards are
based on best practices developed by Microsoft to produce robust and easy-to-
maintain code.
The issues identified by this tool are also an alert sign to the developer that is up-
grading an application to Visual Basic .NET. These issues can be corrected in the
original source code to have a smoother transition. The code advisor tool will not
find every upgrade issue, but it is designed to help locate the most common issues
and speed up the upgrade process. The issues detected by this tool can be extended
using regular expressions.
The following list shows a sample of the predetermined rules that are detected by
this tool:
● Late binding of variant object. An object is late-bound when it is assigned to a
variable declared to be of type Object. Objects of this type can hold references to
any object. When the Visual Basic Upgrade Wizard upgrades a variable whose
type is Object, it cannot identify the specific type of the variable, and none of the
accesses to the corresponding class members are upgraded. This problem can be
fixed by using specific types in the declaration of all variables. This is enforced
using the directive Option Strict On. The Visual Basic 6.0 Code Advisor detects
undeclared variables and suggests the developer use Option Strict On.
● Missing option explicit. Leaving this option undeclared allows the developer to
use undeclared variables in the source code. Undeclared variables default to type
Variant, which can hold a value of any type. Such variables result in the same
upgrade problems as mentioned in the preceding bullet: the upgrade wizard
cannot determine the correct property to use when your code uses the default
property of an object declared as Variant.
● Soft binding of Form or Control. Variables declared as Form or Control can
cause problems when upgrading. In Visual Basic 6.0, these generic classes can
be used with properties and methods that are defined for particular forms and
controls. Form and Control variables are supported in Visual Basic .NET, but
accessing properties that are specific to a particular type of form or control is not
supported.
● Soft binding using ActiveForm and ActiveControl. This usage pattern has the
same upgrade problems as stated in the preceding bullet.
● String functions that return Variant. Visual Basic 6.0 provides a group of string
functions that have two versions, one that returns a Variant, and another that
returns a String (for example, Left and Left$). Variants can contain null values;
assigning a null value to a variable that expects a string may cause a run-time
148 Upgrading Visual Basic 6.0 Applications

error that is difficult to debug. In Visual Basic .NET, only the String version of
these functions is supported.
● OLE control not upgraded. There is no equivalent for the OLE Container control
in Visual Basic .NET. When you attempt to upgrade a form that contains an OLE
Container control, any code for the OLE Container control will not be upgraded.
Instead, the control is replaced by a Label control to highlight the fact that the
OLE Container cannot be automatically upgraded.
● No Line control in Visual Basic .NET. The Line control has no direct equivalent
in Visual Basic .NET. When you attempt to upgrade a form that contains a hori-
zontal or vertical Line control, it will be replaced by a Label control. Non-vertical
and non-horizontal lines are not upgraded at all and must be manually replaced
using graphics function calls in Visual Basic .NET.
● Property/Method/Event not upgraded. The referenced Visual Basic 6.0 property,
method, or event has no direct equivalent in Visual Basic .NET. When the applica-
tion is upgraded, the corresponding line of code will be copied unmodified to the
target code. This will cause a compilation error in Visual Basic .NET.
For more information about the Visual Basic 6.0 Code Advisor, see “Visual Basic 6.0
Code Advisor” in the Microsoft Visual Basic Developer Center on MSDN.

Removing Unused Components

During the lifetime of the original application, it is likely to be modified several
times, potentially changing the dependences between the different components. It is
also possible that some part of a component’s code is no longer used by the rest of
the application.
For clarity and manageability, components or code fragments that are no longer
used in the application should be removed. From the upgrade point of view, it is
also important to remove unnecessary application elements before starting the
process. This reduces the upgrade issues that will be generated after the automated
upgrade and also decreases the quantity of code that needs to be upgraded.
The assessment tool can be used to identify unused components. The file depen-
dence graph reports the relationships between application files. Files that are never
used can be identified by reviewing this report. Third-party components and exter-
nal DLL function references should also be examined to identify additional unused
elements that can be removed.

Obtaining the Application Resource Inventory

The upgrade of an application from one language to another involves many tasks
with different levels of complexity and requirements. The transition from a pro-
gramming language and a development environment to another language that is
hosted in a different environment is an important part of the upgrade, but there are
 Chapter 5: The Visual Basic Upgrade Process 149

additional tasks that have to be done to take full advantage of the new resources and
continue improving the application along its new life cycle in the new platform.
The initial source code inventory made with the assessment tool is essential for the
upgrade effort estimation. When upgrading earlier versions of applications, it is also
important to have an inventory of resources such as documentation, design dia-
grams, test cases, and specifications. These resources are helpful in the final stages of
the upgrade procedure. The original test cases are the basis for testing the upgraded
application. It is important to evaluation design diagrams and similar documenta-
tion to make decisions about the target architecture. This information also helps you
to have a high level view of the application and identify parts or functionality that
require special attention during the upgrade. Database and general design docu-
mentation can also be useful when adjusting the upgraded application. For example,
Variant variables that are used to access database fields can be re-declared with
more specific types using field data type information.

Compilation Verification
The upgrade wizard requires source code to be syntactically correct. This can be
verified by compiling the original application before the execution of the upgrade
wizard. All compilation errors produced in the original application must be cor-
rected to provide an appropriate input to the upgrade wizard. The compilation of
the original application is also useful to verify that all the components and user-
defined source code referenced by the application are available in the system. In the
case of project groups, it is important to confirm that the entire group and individual
projects can be correctly compiled. The upgrade of projects groups is explained in
detail in the next section.
When you try to open a project that references an unavailable component, the
following error message appears:
Errors during load. Refer to ‘C:\ReferenceSample\Form1.log’ for details
You can find the cause of this error message by opening the specified file. A sample
error line might look like the following:
Line 13: Class MSComctlLib.TreeView of control TreeView1 was not a loaded
control class.
To fix this compilation error and allow the upgrade wizard to upgrade this applica-
tion, it is necessary to install the component indicated in the error description. In
this example, it would be necessary to install the MSComctlLib.TreeView compo-
nent.
It is also recommended that you perform a test run of the original application on the
computer where the upgrade will take place. This test run verifies that all compo-
nents are available and that the application is producing the expected results. It is
important to take into consideration that all the run-time errors that exist in the
150 Upgrading Visual Basic 6.0 Applications

original application are likely to remain in the target application. Knowing the errors
contained in the original application provides a basis for testing and improving the
target application. For more information, see the “Testing and Debugging the
Upgraded Application” section later in this chapter.

Project Upgrade Order Definition

The upgrade order of the files contained in a Visual Basic 6.0 application is deter-
mined by the file order specified in the corresponding application project file. This
order also determines which result files are written first in the target application
directory. This information can be useful when testing and isolating problems in the
upgrade of a specific application. A Visual Basic 6.0 application can be composed of
different projects that are independently accessed and managed. The projects can
also be organized in a project group file. For information about upgrading an appli-
cation built using a project group file, see the “Project Group Upgrade” section later
in this chapter.
A project can contain source code files that correspond to the different tiers of the
application. These tiers can also be distributed in different projects. For upgrade
purposes, it is important to clearly understand the correspondence between the
application tiers and the project elements that compose it. The project and compo-
nent upgrade order is determined by the association between components and
application tiers and the component dependencies. Another factor to be considered
when establishing the processing order is the chosen upgrade strategy. A vertical or
horizontal upgrade strategy can be selected based on the criteria explained in
Chapter 1, “Introduction,” and Chapter 4, “Common Application Types.”
The initial approach recommended for the upgrade of an application is to process
the core application components first. These components provide services and
functionality to other elements of the application. An alternative approach is to leave
these basic components for the final stages of the upgrade. The other components
can access them using interoperability techniques to test intermediate upgrade
results.

Determine All Dependencies

When one application component uses another component, the first component is
said to be dependant on the second. There are different types of usage that require
different ways to identify such dependencies. Usage can appear in the form of access
to a class member, invocation of a method, declaration of a variable with a particular
type or the inclusion of an embedded control. Dependencies also exist at the project
level and can be established through project references. The dependency relationship
is transitive, which means that if a component A is dependant on a component B and
B is dependant on a component C, then A is also dependant on C. The terminology
for this is that B is directly dependant on C and A is indirectly dependant on C,
 Chapter 5: The Visual Basic Upgrade Process 151

because there is an immediate dependency between B and C and an intermediate

dependency between A and C.
As previously mentioned, dependencies can be identified based on how one compo-
nent references or accesses another. Dependencies can be easily identified for an
application with few components. However, as the number of components and their
interactions increase, obtaining a complete view of the component dependencies
becomes more difficult. In most cases, considering the dependencies at the project
level will be sufficient for a successful upgrade; however, if there are complex and
difficult-to-upgrade components inside the projects, dependency considerations
should also be applied to them.
The knowledge about the dependencies between components and projects is essen-
tial for the upgrade engineer. This information will be used in conjunction with
other key considerations such as strategic priorities, business value, and available
resources to focus the upgrade efforts and maximize the results obtained.
The assessment tool generates a file dependency graph that is a useful tool to iden-
tify components that have no dependencies. Figure 5.2 illustrates this report.

Figure 5.2
A sample file dependency graph

This report can be used to identify independent components. In this example, the
first project included in the report, Project1.vbp, includes three files: AVICAP.bas,
MemCap.bas, and Watchman.frm. These files have different dependency relation-
ships identified in the report. The files Watchman.frm and AVICAP.bas are included
152 Upgrading Visual Basic 6.0 Applications

in the folder labeled MemCap.bas, which means that MemCap.bas depends on the
other files. Independent user-defined files depend only on third-party components
or system components, such as user32.dll. In this example report, AVICAP.bas is an
independent component because it does not depend on other user-defined files.
The first decision to make regarding component upgrade is whether the indepen-
dent components are going to be upgraded to Visual Basic .NET or are they going to
be accessed through interoperability. This decision should be based on a cost-benefit
analysis, as discussed in Chapter 2, “Practices for Successful Upgrades.” If the
components are not difficult to upgrade and they can benefit from the new .NET
features to produce a better target architecture, the components should be upgraded.
However, if the component is complex, or the benefit of upgrade is not justified by
the cost, it may be best to leave the component in Visual Basic 6.0 and use it in the
new application through interoperability techniques.
After the independent components are processed, you must treat the components
that are directly dependant on the components just upgraded in the same way. This
procedure needs to be repeated for each level of dependant components until the
entire application is processed. This method is a high-level view of the application
upgrade processing order; it can be further refined considering aspects such as the
testing phase and process efficiency and risks: these are discussed later in this
chapter.
If dependency relationships are followed in a systematic way, testing the application
in a progressive way, that is, with an increasing quantity of upgraded components,
will be facilitated. Different testing milestones can be defined in the upgrade plan
according to the dependency graph.
There is an additional consideration that needs to be taken into account when
defining the upgrade plan and component upgrade order: striking a balance be-
tween the pieces of the application that are upgraded and the testing that is applied
to the different components.
One possible strategy is to upgrade a group of the application components and
perform unit testing of the corresponding application functionality at the end of the
upgrade. After the entire application is upgraded, system testing can begin. One
advantage of this approach is that there is a greater degree of parallelism; several
components can be upgraded simultaneously with almost no coordination. The
main disadvantage is the difficulty in isolating problems during the testing phase.
This strategy is recommended for the upgrade of applications with low or mid
complexity. Upgrade complexity is determined by the language features and the size
of the application to be upgraded. For more information, see Chapter 3, “Assess-
ment and Analysis.”
 Chapter 5: The Visual Basic Upgrade Process 153

Another possible strategy is to upgrade the components by strictly following the

order of the dependency graph; this implies testing the application functionality in
an incremental fashion after each component is upgraded. One of the advantages of
this strategy is that problems can be easily isolated. However, an important disad-
vantage is that additional planning and coordination will be necessary during the
project execution. Furthermore, less parallelism is possible in this approach. This
strategy is recommended for the upgrade of applications with high complexity.
As stated in the introductory text of the “Application Preparation” section earlier in
this chapter, it is important to document all important decisions in an upgrade
project log. This document should include the project upgrade order and the infor-
mation that was used to determine it.

Reviewing the Upgrade Wizard Report

As part of the preparation stage, it is important to perform a partial test upgrade of
the application to determine or detect each of the following:
● Upgrade process speed. The time consumed by the upgrade of a part of the
application can provide an idea of the time required to upgrade the entire appli-
cation. This information is useful for the upgrade procedure planning.
● System resources. The available system resources, especially the amount of
system memory, can be evaluated using a part of the application. The consump-
tion of system resources is affected by the application complexity; if system
resources show signs of excessive usage, such as extreme memory swapping
(referred to as thrashing), the resources should be increased.
● Setup problems. Common setup problems, such as unavailable third-party
components or out-of-date source code, can be detected in a partial test upgrade.
● Other common errors. Source code issues can be identified and corrected before
the full upgrade of the application.
The upgrade wizard report generated during the test upgrade can be examined to
get an idea of the amount of manual work that will be necessary after the automated
process. It will provide a vision to plan for the upgrade and prepare the necessary
resources. This report can also be filtered and analyzed as described in Chapter 3,
“Assessment and Analysis.”
The upgrade wizard produces a report that contains errors, warnings, and issues
that are found during the project upgrade. When a project is upgraded, the upgrade
wizard upgrades most of the code to Visual Basic .NET, but some elements cannot be
automatically transformed. These language elements will require manual modifica-
tions after the automated process has finished. The following code example shows
one of the most common scenarios that will produce a warning when upgraded
using the upgrade wizard.
154 Upgrading Visual Basic 6.0 Applications

Sub SetObjLabel(obj As Variant)

obj.Caption = "Initial text"
End Sub
Private Sub Form_Load()
SetObjLabel Label1
End Sub

In this code example, one of the Form’s controls is sent to a subroutine that sets
some initial values. When applied, the upgrade wizard produces the following code.
Sub SetObjLabel(ByRef obj As Object)
'UPGRADE_WARNING: Couldn't resolve default property of object obj.Caption.
obj.Caption = "Initial text"
End Sub
Private Sub Form1_Load(ByVal eventSender As System.Object, _
ByVal eventArgs As System.EventArgs) Handles MyBase.Load
SetObjLabel(Label1)
End Sub

As this shows, much of the code is automatically upgraded to Visual Basic .NET.
However, the line in bold font represents upgrade issues identified by the upgrade
wizard. The comment indicates what the issue is, and the code line is code that
cannot be automatically upgraded by the upgrade wizard. The code is copied
unchanged from the original code base to the upgraded code.
The problem results from late binding of the variable object to a Label object. As
stated earlier in the chapter, late binding cannot be resolved by the upgrade wizard;
it cannot determine the specific object type that is being accessed when the Caption
property is referenced. As a result, it cannot find an equivalent expression for that
property. If this code is built and executed, a run-time exception will be generated.
In most cases, the solution for this problem is to use a more specific data type for the
affected variable and replace the accessed members with the equivalent .NET mem-
bers. This is demonstrated in the following Visual Basic .NET code example.
Sub SetObjLabel(ByRef obj as System.Windows.Forms.Label)
obj.Text = "Initial text"
End Sub

Note that the UPGRADE_ISSUE comment can be removed after the correction is
made.
The subroutine SetObjLabel has a specific purpose that has been accidentally
changed with the correction to the code. In the original application, SetObjLabel
can receive any kind of control that has a Caption property. In the new version, the
subroutine can only receive Label controls. This is an important consideration that
can easily be overlooked. An alternative correction that will maintain the behavior of
 Chapter 5: The Visual Basic Upgrade Process 155

the original code is to change the type of the parameter to

System.Windows.Forms.Control, which has a Text property and is the ancestor of
all .NET controls. This will restore the possibility of accepting any control, as shown
here.
Sub SetObjLabel(ByRef obj as System.Windows.Forms.Control)
obj.Text = "Initial text"
End Sub

Note: The ArtinSoft Visual Basic Upgrade Wizard Companion has an advanced mechanism for
automatic type deduction of undeclared variables. This mechanism performs a static analysis
of the source code based on the usage pattern of most of the Visual Basic 6.0 language
elements and the information they provide regarding the most probable data type of the
involved symbols. The relationships between symbols are also analyzed to obtain a precise
conclusion about the data type of variables, parameters, or other language elements that are
late bound. Using the upgrade wizard companion, the previous code example would have been
automatically upgraded to the code example shown here.

Sub SetObjLabel(ByRef obj as System.Windows.Forms.Label)

obj.Text = "Initial text"
End Sub

Depending on the additional invocations of SetObjLabel, the object parameter would have been
declared as System.Windows.Forms.Control or other control type.
For more information about the upgrade wizard companion and additional upgrade services, go
to the ArtinSoft Web site.

The following list presents the most common upgrade issues and how they can be
solved after the automated upgrade has taken place:
● Property <object>.<property> was not upgraded. This warning is generated
when a property cannot be automatically upgraded. To correct this problem, it is
necessary to use a workaround that replaces the original functionality. It may
require the reimplementation of certain application functionality.
● <objecttype> object <object> was not upgraded. This occurs when objects of
unsupported classes are declared and used. Additional development work may
be necessary to fix this problem. For more information, see Chapters 7 through
10.
● Use of Null/IsNull detected Null is not supported in Visual Basic .NET. Null is
upgraded to System.DBNull.Value and IsNull is changed to IsDBNull. This
value and function do not have the same behavior as in Visual Basic 6.0. Also,
Null propagation is no longer supported in Visual Basic .NET. The application
logic needs to be reviewed to change the usage of Null.
156 Upgrading Visual Basic 6.0 Applications

● <functionname> has a new behavior. Some functions have different behaviors in

Visual Basic .NET. This requires a detailed review of the code to ensure that the
application logic has not been altered.
● <object> event <variable>.<event> was not upgraded. Some events cannot be
upgraded to Visual Basic .NET. The corresponding methods must be called if
necessary.
● Could not resolve default property of object ‘<objectname>’. This is one of the
most common issues you will encounter. It occurs whenever a late-bound vari-
able is set to a value. This is the warning discussed in the previous code example.
● Could not load referenced component <reference>. This message is related to
the setup of the application that is being upgraded. It will be included whenever
a reference, such as an ActiveX control or class library, cannot be found. To
correct this problem, verify that all necessary components are installed on the
computer. This issue can be avoided by installing Visual Basic 6.0, with all refer-
enced components, and ensuring the application compiles and runs before
beginning the upgrade.

For a description of errors, warnings, and issues, see the left pane of “Visual Basic
6.0 Upgrading Reference” on MSDN.

For Visual Basic 2005:

The upgrade wizard included in Visual Studio 2005 has significant differences
from the previous version. These differences include additional support for
more Visual Basic 6.0 features and new upgrade messages among others. The
changes in the upgrade wizard result in fewer errors, warnings and issues
(EWIs) (since more features are now supported) and reorganization of the
distribution of effort required to address identified EWIs.

Application Upgrade
The Visual Basic Upgrade Wizard is the primary tool for application upgrade. This
section describes the execution options that are available and how to get the most
out of the wizard.
The automated application upgrade is the middle stage in the complete upgrade
process. Before the upgrade, it is necessary to prepare and set up all necessary
components. Usually, some manual adjustments are necessary after the automated
upgrade to reach a compileable application with functional equivalence. The en-
hancement of the target application can begin after that.
There are different versions of the upgrade wizard that include different features to
further automate the upgrade result. Most of the upgrade features discussed in this
book apply to the Visual Studio .NET (also known as Visual Studio .NET 2003)
 Chapter 5: The Visual Basic Upgrade Process 157

version of the upgrade wizard. The version of the upgrade wizard included in
Visual Studio 2005 has improved performance and reliability, as well as additional
upgrade capabilities, including support for additional ActiveX controls and im-
proved support for the upgrade of COM+ functionality. The ArtinSoft Visual Basic
Upgrade Wizard Companion as additional upgrade mechanisms that support
context aware upgrade of enumerations, code improvement capabilities, automatic
type deduction for Variant and Object variables, and other advancements. For more
information about this upgrade tool and additional upgrade tools and services, go to
the ArtinSoft Web site.
This section focuses on the Visual Studio .NET upgrade wizard, but when it is
applicable, the features of other versions of the upgrade wizard will be highlighted.
For more detailed information about the upgrade wizard and the automated up-
grade process, see Chapter 6, “Understanding the Visual Basic Upgrade Wizard.”

Execution of the Visual Basic Upgrade Wizard

The upgrade wizard can be used in two ways: it can be used as either a command
line tool or as a wizard available through the Visual Studio .NET IDE. The wizard
version is automatically invoked whenever you attempt to open a Visual Basic 6.0
project file in Visual Studio .NET. Both of these approaches are discussed in this
section.
When performing an upgrade, it is recommended that you install Visual Basic 6.0
and Visual Basic .NET on the computer on which you are conducting the upgrade;
this allows you to test the original and target application and installs basic compo-
nents that are required by the upgrade wizard.
To facilitate the discussion, a sample Visual Basic 6.0 project will be used as an
example for the step of applying the upgrade wizard. The sample project is named
SumApp. When the application runs, the result of the addition of the two input
fields is displayed in a box after the user clicks the command button. The application
verifies that the user has entered appropriate numeric values in the boxes before it
executes the addition.

Accessing the Upgrade Wizard from Visual Studio .NET

This section documents upgrading the sample application using the upgrade wizard
in the Visual Studio .NET IDE. The following steps must be executed to upgrade the
project:
1. Open Visual Studio .NET.
2. On the File menu, click Open, and then click Project. This displays the Open
Project dialog box. Navigate to the location of the Visual Basic 6.0 project file, and
then click the desired project file. For our example, navigate to the location in
which you saved the SumApp project, click SumApp.vbp, and then click Open.
158 Upgrading Visual Basic 6.0 Applications

3. Read the welcome page, and then click Next.

4. On the Choose a project type page, the appropriate option is selected by default.
Click Next.

Note: This page sets the options for the upgrade. There are two available choices to select
the type of application that will be generated for the target project. EXE projects upgrade to
projects that produce an executable file, and DLL/custom control projects upgrade to
projects that produce DLLs. For standard EXE and DLL projects, the upgrade type is
determined automatically. For other types, such as EXE server projects that can act like a
hybrid of an EXE and a DLL, these projects can be upgraded to either Visual Basic .NET EXE
or DLL projects. For this example, the sample application is a standard EXE, so the EXE
option is automatically selected, and the DLL/custom projects upgrade option is unavail-
able.

5. On the Specify a Location for Your New Project page, the wizard suggests the
target directory to be called projectname.NET, where projectname is your original
project’s name. In our example, the suggested name is SumApp.NET. Click Next.

Note: If the destination directory already exists and contains files, a warning is displayed
that indicates that the output directory is not empty. The wizard will ask you to choose
another directory. If he directory does not already exist, a Warning displays that asks for
confirmation to create the directory. Click Yes to create the directory or No to specify a
different target directory. For our example, the SumApp.NET folder should not yet exist, so
click Yes to create the target directory and proceed to the next page of the wizard.

6. The Ready to Upgrade page of the wizard informs you that it is ready to perform
the upgrade. Click Next to start the upgrade.
The next page of the wizard displays information about the upgrade process status.
A Status box shows the task the upgrade wizard is currently executing and a
progress bar indicates an approximation of the time left for the task. The upgrade
can take anywhere from a minute (for a small project such as the sample application)
to several hours (for a project with hundreds of forms and classes). When the pro-
cessing is complete, the new upgraded project opens in Visual Studio .NET. Figure
5.3 illustrates a sample.
The upgraded project has a form module, Form1, that corresponds to the Visual
Basic 6.0 form module in the original project. In Solution Explorer (in the top right
corner of the IDE illustrated Figure 5.3), double-click Form1.vb to open the up-
graded form. The new form should appear similar to the original. Figure 5.4 illus-
trates this.
 Chapter 5: The Visual Basic Upgrade Process 159

Figure 5.3
The sample application after applying the Visual Basic Upgrade Wizard

Figure 5.4
The upgraded form
160 Upgrading Visual Basic 6.0 Applications

To run the upgraded application, press F5. The first time an upgraded project is built
or run, you will be prompted to save the solution file. The .NET solution corre-
sponds to the root of the tree displayed in Solution Explorer. A solution file is similar
to a group file in Visual Basic 6.0. The upgraded project is contained in this solution
file. Accept the suggested name for the solution, and then press Enter to save it. The
project is then automatically built and executed. Form1 is displayed and waits for
user input. Figure 5.5 illustrates the result obtained for sample input data.

Figure 5.5
Execution of the upgraded application

Accessing the Upgrade Tool from the Command Line

The automated upgrade tool can also be applied from the command-line using the
VBUpgrade.exe upgrade program. This program uses the same upgrade engine as
the upgrade wizard accessed in Visual Studio .NET. Assuming the default installa-
tion directory is used, this program can be found in the following path:
drive:\Program Files\Microsoft Visual Studio .NET version\Vb7\VBUpgrade\
In this path, drive indicates the drive letter on which the installation resides and
version indicates the Visual Studio .NET version. For example, this guide was written
for the Visual Studio .NET 2003 IDE, so the full path would be the following:
drive:\Program Files\Microsoft Visual Studio .NET 2003\Vb7\VBUpgrade\
If you installed the upgrade tool to a location other than the default directory, or if
you are otherwise unsure about where the program is located, you can use Windows
Explorer to locate it. The remaining text for this example assumes you have the
directory of this utility in your command search path.
The command-line upgrade tool produces the same results as the upgrade wizard.
To upgrade a project, the project file name and the destination directory need to be
indicated as arguments to the command. If the destination directory does not exist,
the upgrade tool automatically creates it. For example, the following statement
upgrades our sample project, stored in C:\SumApp\SumApp.vbp to the
C:\SumApp\SumApp.NET directory.
vbupgrade c:\SumApp\SumApp.vbp /Out c:\SumApp\SumApp.NET
 Chapter 5: The Visual Basic Upgrade Process 161

Note that you should replace the directory names with the appropriate locations.
The command-line version of the upgrade tool does not have wizard pages. Further-
more, this tool does not delete any files in the destination directory. If the destina-
tion directory already exists and contains files, the command-line tool stops running
and returns an error.
It is recommended to use the command-line tool when the available memory on the
upgrade system is limited. Using this tool saves the system resources needed by
Visual Studio .NET when the upgrade tool runs. Depending on the system configu-
ration, Visual Studio .NET consumes approximately 15 MB of memory.

Command Line Options

The command-line version of the upgrade tool has many options that you can
specify when performing an upgrade. You can obtain a complete list of the available
options for this tool by entering the following command at the command prompt:
vbupgrade /?
This command displays a welcome message followed by the available option
switches and their meanings.
Microsoft (R) Visual Basic.NET Upgrade Tool Version 7.00.9238.0
Copyright (C) Microsoft Corp 2000-2001.
Portions copyright ArtinSoft S.A.
All rights reserved.
Usage: VBUpgrade <filename> [/Out <directory>] [/NoLog • /LogFile <filename>] [/
Verbose] [/GenerateInterfaces]
/? Display this message
/Out Target directory (default is ".\OutDir")
/Verbose Outputs status and results
/NoLog Don't write a log file
/LogFile Log file name (default is
"<ProjectFileName>.log")
/GenerateInterfaces Generates interfaces for public classes

The tool has a verbose mode that allows a user to identify exactly what the tool is
currently doing. This is useful as a way to determine the upgrade progress of large
applications. If you use this tool while upgrading the sample application, the tool
returns the following.
C:\Program Files\Microsoft Visual Studio .NET 2003\Vb7\VBUpgrade>vbupgrade
C:\SumApp.vbp /Verbose
Microsoft (R) Visual Basic.NET Upgrade Tool Version 7.00.9238.0
Copyright (C) Microsoft Corp 2000-2001.
Portions copyright ArtinSoft S.A.
All rights reserved.

Initializing...
Parsing Form1.frm...
162 Upgrading Visual Basic 6.0 Applications

Loading User Type Library Form1

Pre-processing Form1...
Upgrading Form1...
Upgrading Form1.Form1
Upgrading Form1.Command1
Upgrading Form1.Text2
Upgrading Form1.Text1
Upgrading Form1.Label1
Upgrading Form1.Command1_Click
Writing Form1.vb...
Writing Form1.resx...
Writing project file Project1.vbproj...
Writing project file Project1.vbproj.user...
Writing project file _UpgradeReport.htm...
Writing AssemblyInfo.vb...
Writing project file Project1.vbproj...
Writing project file Project1.vbproj.user...
Writing project file _UpgradeReport.htm...

Note that the preceding example assumes the default installation location for Visual
Studio .NET. In this sample output, the user can see the different stages that are
involved in the upgrade of a Visual Basic 6.0 project. It is important to note that
some of the output lines may take some time to appear, sometimes several minutes,
while the tool is executing. The state of the upgrade process can be checked using
the Windows Task Manager, as discussed in the next section.

Project Group Upgrade

With Visual Basic 6.0, developers can group different projects into a single project
group file. When a group file is compiled, all projects specified in the group are
compiled together. Furthermore, the debugger can navigate through the code in all
projects. This functionality is useful when there are project dependencies in the
application. The upgrade wizard does not support project groups, primarily because
of the size of the context information that must be simultaneously managed for all
the projects.
In Visual Basic .NET, the equivalent for a project group is a solution. A solution can
contain projects written in different languages with references between them. The
projects are compiled and debugged together just as in a Visual Basic 6.0 project
group.
Testing an upgraded application with moderate complexity to high complexity
requires at least the same effort as testing the original application. The testing of
some of the application functionality can be performed in parallel with the upgrade
of other components. These parallel tasks require coordination and the definition of
a project upgrade order accordingly. For more information, see the “Testing and
Debugging the Upgraded Application” section later in this chapter.
 Chapter 5: The Visual Basic Upgrade Process 163

Depending on the strategy used for intermediate result testing, the following project
upgrade orders might be followed:
● First upgrade the projects that have no dependencies. If the core functionality is
upgraded first, testing can be done at different levels, starting from the core
components and including more functionality in each iteration. This approach
provides isolation of problems and can be used for upgrade projects with high
complexity and that do not require early demonstrations of upgraded functional-
ity.
● First upgrade the projects on which no other projects depend. The components at
the top of the dependency hierarchy can be upgraded first and if necessary the
application functionality can be tested using interoperability for the remaining
components. This approach can produce early demonstrations of upgraded
functionality, but it may require additional effort for the creation of
interoperability wrappers.
A mixed approach can also be used to obtain a combination of benefits.
The following example shows how to upgrade a project group using the first ap-
proach explained. The sample project group has two projects; one of them generates
a DLL that contains a class used to perform addition operations. The second project
is a front-end program that displays a form that asks the user for input and uses the
services provided by the DLL. When the project group is compiled and the gener-
ated program is executed, a form displays that asks the user for numerical values to
be added. If an incorrect value is entered, an error is raised in the DLL and the form
displays the error description. The sample application can be found on the compan-
ion CD.
To upgrade this project group when the priority is placed on the core components,
the following steps must be performed:
1. Open the Group1.vbg file group in Visual Basic 6.0.
2. Using the upgrade wizard, upgrade all projects that have no dependencies. Each
project must be processed individually, as follows:
a. In Visual Basic 6.0, observe the references associated with Project1. In the
projects window, select Project1. By default, this is at the upper-right corner of
the IDE. In the Project menu select References. The References - Project1.vbp
dialog box displays.
b. The References – Project1.vbp dialog box shows that Project1 depends on
Utilities. The Utilities project has no further dependencies, so it should be
upgraded first. For large applications, this kind of dependency analysis can be
done with the Assessment Tool File dependency graph, as explained in the
“Determine All Dependencies” section earlier in this chapter. Upgrade the
Utilities project using the upgrade wizard, as explained in the “Accessing the
Upgrade Wizard from Visual Studio .NET” section.
164 Upgrading Visual Basic 6.0 Applications

3. After Visual Basic .NET is opened, the dependant project can be upgraded and
added to the solution. On the File menu, point to Add Project, and then click
Existing Project. This opens the Add Existing Project dialog box. Click
Project1.vbp, and then click Open to start the upgrade. Accept the default up-
grade options, as described in the “Accessing the Upgrade Wizard from Visual
Studio .NET” section.
4. Replace the newly upgraded project references with the corresponding .NET
project. To do so, apply the following steps:
a. In Solution Explorer, open the Project1 project folder. Open the References
folder. Right-click Utilities, and then click Remove. This removes the reference
to the old version of Utilities.
b. To add a new reference to the new Visual Basic .NET version of the Utilities
project, right-click the References folder, and then click Add Reference. The
Add Reference dialog box displays. To view the available projects, click the
Projects tab. To add the reference, double-click Utilities, and then click OK.

Note: Now that the reference to the original Visual Basic 6.0 version of Utilities has been
replaced by the newly upgraded version, there may be differences in its interfaces and data
types. These differences will produce compilation or run-time errors in the places where
this component is accessed. When Project1 was upgraded in step 3, the upgrade wizard
considered the reference to the original version of Utilities and it was treated as an external
third-party component. An interoperability wrapper was generated and no transformations
were applied to the member declarations. Because of this, the usages of this component
inside Project1 will remain the same. The differences can arise when the Utilities library is
upgraded. The upgrade wizard will transform some of its interface declarations and there-
fore the places where the component is used must be updated. These changes include
event parameters and upgraded data types.

5. Review the accesses to Utilities inside Project1, and updated them if necessary.
For our example, the Utilities interface has not changed during the upgrade and
there are no modifications needed in Project1. However, with more complex
interfaces and data types, additional work will likely be necessary to make the
application compile.
6. The solution is now ready to be compiled, run, and tested. Set Project1 as the
startup project by right-clicking it in Solution Explorer, and then clicking Set as
StartUp Project.
7. Now that these two projects are upgraded, you can apply the corresponding
tests. After this subset of the full application functionality is tested and corrected,
a new level of functionality can be upgraded and tested on a stable base. For our
current example, there are no further projects in the group to upgrade, so the
process is complete.
 Chapter 5: The Visual Basic Upgrade Process 165

Alternatively, this project can be upgraded with initial emphasis on those projects
that no other projects in the group are dependent on. To apply this strategy, the
following steps must be performed:
1. Open Visual Studio .NET.
2. Upgrade one of the projects that no other projects in the group depend on. For
this sample project group, no project depends on Project1, so it will be upgraded
first. Follow the procedure in the “Accessing the Upgrade Wizard from Visual
Studio .NET” section.
3. Next, upgrade a project that provides services to the project upgraded in step 1.
For this example, the only project that is used by Project1 is Utilities. In Visual
Basic .NET, click Add Project on the File menu, and then click Existing Project.
This opens the Add Existing Project dialog box. Click Utilities, and then click
Open. Accept the default upgrade options.
4. Project1 still references the Visual Basic 6.0 version of Utilities. This reference
must be deleted and replaced with a reference to the upgraded Visual Basic .NET
version of this project. To remove the reference, expand the Project1 references
node and remove the reference to Utilities by right-clicking it and then clicking
Remove.
5. Add a reference to the new Utilities project: Right-click Project1 References, and
then click Add Reference. In the Add Reference dialog box, click the Projects
tab, double-click Utilities, and then click OK.
6. See step 5 in the previous procedure for additional considerations when replacing
the Utilities reference from the Visual Basic 6.0 version of the component to the
Visual Basic .NET version. The same issues are possible despite a change in the
order of component upgrade.
7. The solution is ready to be compiled, run, and tested. Note that after step 2,
Project1 may be tested using the non-upgraded version of Utilities through
interoperability.

Although the example used to illustrate these two procedures was relatively small,
keep in mind that either of these upgrade approaches can be applied to project
groups composed of many projects. The approach you choose to apply should be
based on careful analysis of the components and their dependencies. A project group
containing many components with no dependencies will likely benefit from the
application of the first upgrade approach presented. Alternatively, a project group
with many components that have no other components dependent on them may
benefit from the second approach.
166 Upgrading Visual Basic 6.0 Applications

Verifying the Progress of the Upgrade

When the upgrade tool is executed from the command line, two processes are
launched:
● VBUpgrade.exe. This is the front end of the tool for the command line mode.

● VBUD.exe. This is the upgrade engine.

The same upgrade engine is launched when the upgrade wizard is accessed in
Visual Studio .NET, but in this case, the only process that will be launched is
VBUD.exe.
The Windows Task Manager displays the two upgrade processes launched by the
command-line version of the upgrade tool.
The upgrade wizard for the 2003 version of Visual Studio .NET processes source
code files one by one and stores each result as a temporary file. After all files are
processed in that way, the final Visual Basic .NET source code is written to the
output directory. This is the final result delivered to the user. If there was a problem
during the upgrade of a file and the upgrade tool has to terminate execution, any
previous temporary results will be lost and no final Visual Basic .NET results will be
obtained. To avoid this situation, the Visual Basic 2005 version of the upgrade
wizard and the Visual Basic Upgrade Wizard Companion from ArtinSoft produce
the final upgrade results on a file-by-file basis. After a file is processed, the final
source code is written and the target project and solution files are updated. This
allows the user to use the results, even if a fatal error occurred during the upgrade of
another file.

Fixing Problems with the Upgrade Wizard Execution

This section includes some common problems that may arise when running the
upgrade wizard. In general, the upgrade process can be left unattended after all the
required information is provided. However, large applications may take several
hours; while it is upgrading, different situations that require user attention may
arise. The following list presents the most common issues that might occur:
● Memory swapping. When the computer that is used for the upgrade of an
application does not have sufficient memory resources for the processing of a
large application, the operating system tries to provide additional memory to the
upgrade process by swapping memory to disk. The swapping back and forth
between memory and disk may consume more processing power than the other
tasks. In this situation, the system is said to be in a “thrashing” state. In this state,
the upgrade process can take a significant amount of additional time to finish.
When this occurs, it is recommended that you stop the automated upgrade,
increase the system memory, and begin the automated upgrade again. Figure 5.16
illustrates a system that is upgrading a huge application and is in a thrashing
state. Notice that all the processor time is consumed by the kernel and almost all
the memory is used.
 Chapter 5: The Visual Basic Upgrade Process 167

Figure 5.6
The Windows Task Manager Performance display in a typical “thrashing” scenario
● Incorrect references. When an application has more than one project to be up-
graded, you may choose to upgrade one project at a time. You can make some
source code reorganization according to upgrade priority or other factors. If a
reference to a user project or a third-party component is accidentally changed to
another reference during this reorganization, the upgrade wizard will not be able
to obtain all the necessary information about members and data types. This will
generate warnings about default property extraction in all places where members
of these components are used, because none of these members will be automati-
cally upgraded by the upgrade wizard. If this happens, the corresponding refer-
ence and accesses to the elements contained in it will have to be reviewed.
● Trial version of third-party components. The upgrade wizard loads all third-
party components referenced in the project. Some trial version components
display a license dialog box and wait for user input whenever the components is
instantiated. This will cause the upgrade process to stop until the dialog box is
closed. You should pay attention to these dialog boxes to allow the upgrade
process to continue.
● Upgrade wizard exceptions. It is an unusual scenario, but when a file is being
processed by the upgrade wizard, it may be possible for the tool to encounter a
fatal problem. For example, third-party components with a nonstandard interface
or other conditions will produce an exception. In this case, the upgrade tool will
terminate execution. The first step to solve this problem is to isolate the file and
168 Upgrading Visual Basic 6.0 Applications

source code that is producing the exception. After this is done, the source code
can be commented. After the problematic code is removed, the upgrade process
can be started again. You may want to report these types of exceptions to
newsgroups so that other developers can avoid them. Some suggested
newsgroups are microsoft.public.dotnet.languages.vb.upgrade and
microsoft.public.dotnet.languages.visualbasic.migration.

Being aware of and planning ahead for known exceptions can help you to have a
smoother upgrade.

Completing the Upgrade with Manual Changes

After the upgrade wizard is applied to a Visual Basic 6.0 project resulting in Visual
Basic .NET code, it is often be necessary to make adjustments to the upgraded code
to make it run in the new environment. This section discusses some of the changes
you may need to make.

Reaching a Buildable State

The first step in this process is to make the application compile in Visual Studio
.NET. Before the application is compiled, you should review the project references to
ensure all necessary references are present and correct. In Solution Explorer, open
the References folder in the corresponding project and verify that all references are
correctly included. If there is a warning icon next to a reference, the most probable
reason is that there was a problem generating an interoperability wrapper or includ-
ing it in the project. The reference must be removed and then manually added again
to remove the warning state.
After the project references are verified, you can attempt to build the new version of
the application. On the Build menu, click Build Solution.
The Visual Studio .NET IDE allows developers to identify and navigate through all
the compilation errors that were found. Moreover, the Task List shows all problems
that were detected; you can double-click on any one of the lines to go to the specific
line of code that caused the problem. The problems can be fixed using the informa-
tion provided in the Task List item and applying the techniques shown in Chapters 7
through 11.
After the application compiles successfully, the design time visualization of the
application forms and controls can be verified. Design-time code can be checked by
opening each form and verifying that all controls are correctly displayed. If a control
is not visible, verify the corresponding reference and look for unsupported features.
After the general verification is complete, the testing and debugging phase can begin.
The following section presents some of the most common issues generated during
the automated portion of the upgrade. These issues will be reported by the upgrade
wizard and will produce compilation errors in Visual Basic .NET.
 Chapter 5: The Visual Basic Upgrade Process 169

Common Compilation Errors

This section presents some of the most common compilation errors caused by
unsupported features of Visual Basic 6.0. The upgrade wizard will not upgrade these
issues because there is no equivalent functionality in Visual Basic .NET or there is
implicit information in the original source code that is explicitly required. For each
issue, code examples in original Visual Basic 6.0 and the auto-generated Visual Basic
.NET are provided, in addition to a discussion about the modifications needed to
correct the problem. The objective of this section is to illustrate the general proce-
dure and techniques necessary to correct problems that can arise after an application
has been upgraded to Visual Basic .NET. For information about specific unsupported
features, see Chapter 8, “Upgrading Commonly-Used Visual Basic 6.0 Language
Features.”
By far, the most common upgrade problem reported by the upgrade wizard in
typical Visual Basic 6.0 applications is the default property extraction problem
caused by lack of information about the data type of a variable. Depending on the
usage of the variable, this problem can cause compilation or run-time errors. For
example, the following comment will be generated by the upgrade wizard when this
problem arises:
'UPGRADE_WARNING: Couldn't resolve default property of object MyObj.MyProperty.

To correct this problem, apply the techniques presented in the “Reviewing the
Upgrade Wizard Report” section earlier in this chapter.
The following sections present additional upgrade issues that are detected by the
upgrade wizard and require user intervention to be corrected.
Problems with As Any Parameter Type
When external DLL functions are accessed in Visual Basic 6.0, it is often necessary to
include As Any parameters in the corresponding function parameter declaration.
This data type is no longer supported in Visual Basic .NET. The problem caused by
this change is demonstrated through the following example Visual Basic 6.0 code.
Private Declare Function SystemParametersInfo Lib "user32" _
Alias "SystemParametersInfoA" (ByVal uAction As Integer, ByVal uParam As _
Integer, ByRef lpvParam As Any, ByVal fuWinIni As Integer) As Integer

Private Function GetKeyBoardDelay() As Integer

Const SPI_GETKEYBOARDDELAY As Integer = 22
Dim delayVal As Integer
Call SystemParametersInfo(SPI_GETKEYBOARDDELAY, 0, delayVal, 0)
GetKeyBoardDelay = delayVal
End Function
170 Upgrading Visual Basic 6.0 Applications

Running the upgrade wizard results in the following.

'UPGRADE_ISSUE: Declaring a parameter 'As Any' is not supported.
Private Declare Function SystemParametersInfo Lib "user32" _
Alias "SystemParametersInfoA"(ByVal uAction As Short, ByVal uParam As Short, _
ByRef lpvParam As Any, ByVal fuWinIni As Short) As Short

Private Function GetKeyBoardDelay() As Short

Const SPI_GETKEYBOARDDELAY As Short = 22
Dim delayVal As Short
Call SystemParametersInfo(SPI_GETKEYBOARDDELAY, 0, delayVal, 0)
GetKeyBoardDelay = delayVal
End Function

The latter code will produce a compilation error in Visual Basic .NET caused by the
usage of an unknown As Any data type. To correct this problem, it is necessary to
investigate the specification of the external function SystemParametersInfo. This
function gets the value of system parameters based on the uAction parameter and
stores the result in the lpvParam parameter. The lpvParam parameter data type
must be changed to a specific data type according to the usage of the function in the
source code. In this case, the system parameter to be obtained is the keyboard auto-
repeat delay, and the expected result is a short type. To fix this problem, change the
As Any data type to As Short.
For more information about correcting this error, see Chapter 13, “Working with the
Windows API.”
Changes to Properties of Commonly Used Objects
The following source code compiles and runs perfectly in Visual Basic 6.0; however,
when it is upgraded to Visual Basic .NET, a compilation error result because of an
unsupported property, as shown here.
' List1 is a list box that is embedded in the current Form
List1.AddItem "Hello"
List1.ListIndex = List1.NewIndex

After the upgrade wizard is applied to the code, the following code results.
' List1 is a list box that is embedded in the current Form
List1.Items.Add("Hello")
' UPGRADE_ISSUE: list box property List1.NewIndex was not upgraded.
List1.SelectedIndex = List1.NewIndex
 Chapter 5: The Visual Basic Upgrade Process 171

This code results in a compilation error in Visual Basic .NET because the NewIndex
property is used to retrieve the index of the item most recently added to a ListBox
control. However, the value of NewIndex cannot always be determined in the
upgraded code. This error can be corrected by saving the return value of the Add
method, which is the index of the newly added item. This is demonstrated in the
following code example, with changes highlighted in bold.
' List1 is a ListBox that is embedded in the current Form
Dim NewIndex As Integer
NewIndex = List1.Items.Add("Hello")
List1.SelectedIndex = NewIndex

Discontinued Support for GoSub

The GoSub directive available in Visual Basic 6.0 can be used to branch a program’s
execution to a subroutine or label. The following code example demonstrates the use
of On…GoSub in Visual Basic 6.0.
Function Decide(v As Integer) As String
On v GoSub case1, case2, case3
case1:
Decide = "case1"
Exit Function
case2:
Decide = "case2"
Exit Function
case3:
Decide = "case3"
Exit Function
End Function

Applying the upgrade wizard to this code results in the following.

Function Decide(ByRef v As Short) As String
' UPGRADE_ISSUE: On...Gosub statement is not supported.
On v GoSub case1, case2, case3
case1:
Decide = "case1"
Exit Function
case2:
Decide = "case2"
Exit Function
case3:
Decide = "case3"
Exit Function
End Function
172 Upgrading Visual Basic 6.0 Applications

The On … GoSub construct is no longer supported in Visual Basic .NET. The up-
graded code produced by the upgrade wizard causes a compilation error. However,
the code can corrected by removing the problematic construct, as demonstrated
here.
Function Decide(ByRef v As Short) As String
If v = 1 Then
Decide = "case1"
ElseIf v = 2 Then
Decide = "case2"
ElseIf v = 3 Then
Decide = "case3"
End If
End Function

Changes in Multiple Document Interface Form (MDI) ActiveForm

In Visual Basic 6.0, an MDIForm can refer to its active child form using the
ActiveForm property. Controls in this form can be accessed as properties. In Visual
Basic .NET, ActiveForm is a generic type that has no controls.
The following sample source code works fine in Visual Basic 6.0.
' It is assumed that MDIForm1 has a child form called Form1. Form1 is currently
' displayed and has a Label control called Label1.
Dim controlStr As String
controlStr = MDIForm1.ActiveForm.Label1.Caption

When the upgrade wizard is applied, the following output is produced.

Dim controlStr As String
' UPGRADE_ISSUE: Control Label1 could not be resolved because it was within the
' generic namespace ActiveMDIChild.
controlStr = MDIForm1.DefInstance.ActiveMDIChild.Label1.Caption

As noted in the UPGRADE_ISSUE comment, the Label1 control can no longer be

resolved in the upgraded code because of the change in ActiveForm. To correct this
problem, it is necessary to make an explicit type cast with the corresponding Form
class and manually upgrade the accessed control member. This is demonstrated in
the following code example.
Dim controlStr As String
controlStr = CType(MDIForm1.DefInstance.ActiveMdiChild, Form1).Label1.Text

The issues presented in this section have shown the most common manual changes
you will have to apply to code produced by the upgrade wizard. However, this is
not a comprehensive list. For information about other upgrade issues and the
manual corrections you will have to apply to fix them, see Chapters 7 through 13.
 Chapter 5: The Visual Basic Upgrade Process 173

Testing and Debugging the Upgraded Application

The objective of the testing and debugging phase is to identify and correct problems
that appear when running the application. This section explores testing and debug-
ging of your upgraded application.

Upgrade Report Issues

The following types of issues might be included in the upgrade report and will need
to be addressed:
● Upgrade issues. These indicate unsupported class members or language ele-
ments. For each item identified, the functionality needs to be reviewed, and some
of the affected expressions will require manual upgrade to similar .NET elements.
Each upgrade should be tested in a limited scenario.
● Upgrade ToDos. These identify points in the source code that require user inter-
vention. The instructions included in these items should be followed. Testing of
the resultant code verifies that corrections were properly applied.
● Upgrade warnings. These items identify source code that will compile but may
generate a run-time error. This code needs to be thoroughly tested to identify if
and how run-time errors occur. Additional changes to prevent the occurrence of
the run-time errors may be necessary.
● Design errors. These problems arise when unsupported design-time properties
are used. Members whose behaviors have changed are also included here. The
functionality that these members provide can be redesigned or changed by
similar .NET elements. The code needs to be tested to determine whether the
behavior differences have affected the core application functionality.
● Global warnings. Global issues such as the lack of deterministic object lifetime
because of garbage collection are included here. Most of these warnings are
caused by setup issues that can be easily fixed and tested. Other warnings require
more work to be fixed, such as manual upgrade in the case of source code lines
that are not recognized by the upgrade wizard.
● Upgrade notes. These are generated when the source code has been significantly
altered or the resultant code has some behavior differences from the original
Visual Basic 6.0 version. The code needs to be tested to determine whether the
behavior differences have affected the core application functionality.
Unit and system testing should be performed for all the upgraded application
functionality. During this phase, the original application specifications and te