Context
Many companies continue to rely on Visual Basic 6.0 applications to support their businesses. Microsoft has provided tools and guidance to help with the migration of code from Visual Basic 6.0 to Visual Basic .NET that provides a smooth migration process for much of that code. For Visual Basic 6.0 forms-based applications, however, the migration experience can be less than optimal due to the differences between the Visual Basic 6.0 and WinForms engines. In addition, the heavy reliance on third-party controls by many Visual Basic 6.0 forms-based applications adds to the complexity and number of issues faced when attempting to convert the code.
The reality is that for all but the most basic forms-based applications the best approach for migration is to create a new application in Visual Basic .NET and migrate the functionality from the Visual Basic 6.0 application to the .NET application manually. For many organizations, this is simply not an option for the following reasons:
- 'All or Nothing' Model Not Always Acceptable: There may not be a business (or technological) justification for migrating 100% of an application's forms to .NET. Some organizations may want/need to continue leveraging their existing investment in Visual Basic 6.0 Forms and augment that investment with new functionality developed in .NET.
- Unacceptable Conversion Timeline: Migrating a large forms-based application from Visual Basic 6.0 to Visual Basic .NET can often take several months of development and testing. The timeline could be longer if functional changes or enhancements are included in the migration. Many organizations can not afford to go this long between releases of their LOB applications.
- Unacceptable Risk: Even if the code is converted from Visual Basic 6.0 to .NET using a conversion tool, for many organizations it is an unacceptable level of risk to port an entire application from Visual Basic 6.0 to Visual Basic .NET in a single step.
The primary goal of this Toolkit is to provide guidance and tools to help customers build Hybrid Applications that will enable them to migrate their Visual Basic 6.0 forms-based applications to .NET in a phased manner that is aligned with both the business and technology drivers.
Divide And Conquer
When deciding how to migrate an application, you must identify which pieces will be moved to .NET in a given phase. From both a design and debugging standpoint, the easiest way to proceed is to define logical subsystems of functionality. Each subsystem contains forms that are closely related in business functionality, and have the most intimate relationships and points of connectivity. Breaking an application into subsystems minimizes the amount of communication that must flow through the Interop layer and therefore provides a simpler development experience. In the installed Hybrid Sample Application, Product, Order and Customer subsystems have been defined. This exemplifies one subsystem that remains all Visual Basic 6.0 code, one that is made of both Visual Basic 6.0 and .NET components, and one that has been fully migrated to .NET, respectively.
Cross-Subsystem Communication
While one goal should be to minimize the amount of interoperability points, different subsystems can still communicate with each other. When communicating from Visual Basic 6.0 to .NET, methods and properties should be called. When communicating from .NET to Visual Basic 6.0, events should be raised. Some events make sense to be raised directly from a form, e.g. in response to user interaction. Other events, especially those that communicate a change in application state, may come from non-Form objects. For information on raising events from .NET Forms see How to Create a Custom Event. For information on raising events from .NET Forms see How to Raise an Application-Level Event.
Start Building
Once you've decided what pieces to migrate to .NET you are ready to begin Creating and Working with InteropForms and Creating and Working With Interop UserControls.