Click to Rate and Give Feedback
MSDN
MSDN Library
Visual Studio 2005
Visual Studio
Visual Basic
 Preparing a Visual Basic 6.0 Applic...

  Switch on low bandwidth view
This page is specific to
Microsoft Visual Studio 2005/.NET Framework 2.0

Other versions are also available for the following:
Visual Basic Concepts 
Preparing a Visual Basic 6.0 Application for Upgrading 

Although the process of upgrading a Visual Basic 6.0 application to Visual Basic 2005 is for the most part automatic, there are a number of things you can do to optimize your upgrade with a little bit of preparation.

By following the recommendations in this topic, you can minimize and, in some cases, eliminate the changes needed after upgrading your project to Visual Basic 2005. In most cases, the recommendations simply represent good programming practices; however, some also identify the objects and methods which have no equivalents, and which should be used sparingly if you intend to upgrade your project to Visual Basic 2005.

General Recommendations

This may seem obvious, but if your project doesn't compile and run under Visual Basic 6.0, it will not be upgraded successfully. We recommend that you install Visual Basic 6.0 on the computer that you will be using for upgrading. In addition to allowing you to test the application, this will ensure that all necessary controls, components, and type libraries are available during upgrade.

Visual Basic 2005 allows you to upgrade Visual Basic 6.0 projects; if you have a project written in Visual Basic version 1 to 5, you should first load it into Visual Basic 6.0 (choosing to upgrade Microsoft ActiveX controls), compile, and save the project before upgrading it to Visual Basic 2005.

Considerations for Forms and Controls

Visual Basic 2005 has a new forms package, Windows Forms. Windows Forms is largely compatible with the forms package found in Visual Basic 6.0; however, there are some key differences that are outlined below:

  • Visual Basic 2005 does not support the OLE container control; you should avoid using this control in your Visual Basic 6.0 applications.

  • There is no shape control in Visual Basic 2005. Square and rectangular shapes will be upgraded to labels, while ovals and circles cannot be upgraded. You should avoid using these in your applications.

  • There is no line control in Visual Basic 2005. Horizontal and vertical lines are upgraded to labels. Diagonal lines are not upgraded, and you should avoid using them.

  • Visual Basic 2005 has a new set of graphics commands that replace the Form methods Circle, CLS, PSet, Line, and Point. Because the new object model is quite different from Visual Basic 6.0, these methods cannot be upgraded.

  • For the Timer control, setting the Interval property to 0 does not disable the timer; instead the interval is reset to 1. In your Visual Basic 6.0 projects, you should set Enabled to False instead of setting the Interval to 0.

  • Visual Basic 2005 has two menu controls, MenuStrip and ContextMenuStrip, whereas Visual Basic 6.0 has one menu control that can be opened as either a MainMenu or a ContextMenu control. All menu controls are upgraded to a single MenuStrip component containing MenuItems for each menu control; you will have to recreate your context menus and delete the extra MenuStrip controls.

  • Visual Basic 2005 has no support for Dynamic Data Exchange (DDE).

  • Visual Basic 2005 does not support the Form.PrintForm method.

  • Although Visual Basic 2005 has support for drag-and-drop functionality, the object model is different from the one in Visual Basic 6.0. Therefore, the Visual Basic 6.0 drag-and-drop properties and methods cannot be upgraded.

  • Visual Basic 2005 has an improved Clipboard object (My.Computer.Clipboard) that offers more functionality and supports more Clipboard formats than the Visual Basic 6.0 Clipboard object. However, because of differences between object models, Clipboard statements cannot be automatically upgraded.

  • Visual Basic 2005 does not support the Name property for forms and controls at run time; therefore you should not write code that iterates the Controls collection looking for a control with a certain name. (This functionality is now available using the .NET Framework System.Reflection classes.)

Data Recommendations

Visual Basic 2005 introduces an enhanced version of ADO called ADO.NET that is optimized to work with data in distributed applications and that provides performance improvements over ADO when used in distributed applications.

RDO and ADO can still be used in code from Visual Basic 2005, with some trivial modifications. However, Visual Basic 2005 does not support DAO and RDO data binding to controls, data controls, or RDO User connection. We recommend that if your applications contain DAO or RDO data binding you either leave them in Visual Basic 6.0 or upgrade the DAO or RDO data binding to ADO before upgrading your project to Visual Basic 2005, as ADO data binding is supported in Windows Forms. Information on how to upgrade DAO or RDO to ADO in Visual Basic 6.0 is available in the Visual Basic 6.0 Help.

Web Architecture Recommendations

Visual Basic 2005 introduces ASP.NET, an enhanced version of ASP, and adds to the architecture with Web Forms, a technology for producing Web pages with a Visual Basic-like event model. The architecture is server-based.

Web-based applications that meet the following criteria will be the easiest to upgrade:

  • Follow Microsoft multitier architectural guidelines.

  • Use Active Server Pages.

  • Use Visual Basic 6.0 or Visual C++ 6.0 COM objects for business logic.

ASP is fully supported in Visual Basic 2005, and you can continue to extend your application using ASP, ASP.NET, and Web Forms. The Visual Basic 6.0 and Visual C++ 6.0 business objects can either be used without modification or upgraded to Visual Basic 2005.

Webclasses no longer exist in Visual Basic 2005. Existing Webclass applications can interoperate with Visual Basic 2005 Web Forms and ASP applications, or they can be upgraded to Web Forms applications.

See Also

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Preparing your VB architecture before upgrading      Richard Vantrease   |   Edit   |   Show History

Assuming you have tried to automagically upgrade your VB6 application to .Net and have failed miserably...

I have discovered from experience that applications that were poorly written in VB6 will probably not upgrade automagically to .Net.  One solution to this problem is to clean-up the architecture in VB6 before attempting to upgrade.

I support a VB6 application that was written as a LARGE monolithic application with much of the code in either in the forms or module files instead of classes.  To do the upgrade to .Net, I am first cleaning up the existing VB6 code.

Things to watch for are; dead code, globals, code in module files, and heavy forms.  Clean these up first.

Tags What's this?: Add a tag
Flag as ContentBug
My own Strategy to Migrate VB6 Applications to VB.Net. (time consuming, but worth)      Rajesh Giri   |   Edit   |   Show History

There is no tool/wizard intelligent enough to take advantage of OOPs, Multithreading, Ado.Net and other features of .NET.

You will have to do lot of manual work before migrating any VB6 application to .Net, if you want to take real advantage of moving it to .Net.

If you blindly move it .Net using Wizards, then be ready to maintain it, no good developer would like to work/maintain on such a junk code.

My own Strategy to Migrate VB6 Applications to VB.Net. (It takes time, but worth)

Step 1: Use Code advisor for Visual Basic 6 from microsoft, to do Pre-Migration changes (VB 6 Code Cleanup) (Manual/Automation)

Step 2: Decouple the presentation and business logic (There are lot of VB6 applications in which business logic is merged with presentation logic, in the form of event code). (Manual)

Step 3: Change your VB6 application, so that it will easy to use Micosoft Application Blocks (Manual)

Step 4: Migrate VB6 code to VB.Net using Microsoft Upgrade Wizard. (Automation)

Step 5: Do the code analysis to use Microsoft Application Blocks. (Manual)

Step 6: Try to use ADO.Net/Multithreading where ever possible. (It will definatly shootup application performance) (Manual)

Step 7: After complete migration, you need rigourous testing, your business logic may change because of datatypes (variants/objects). (Manual)


Tags What's this?: Add a tag
Flag as ContentBug
Very large projects - you are on your own 8-(      mike_10   |   Edit   |   Show History
I have found with very large projects that not even the code advisor will run let alone the upgrade wizard.

Looks like we are on our own chaps!
Tags What's this?: Add a tag
Flag as ContentBug
Processing
© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker