Chapter 7: Upgrade Wizard Ins and Outs
7 Upgrade Wizard Ins and OutsThis chapter focuses on the Visual Basic .NET Upgrade Wizard. Specifically, we'll look at the approach the Upgrade Wizard takes to upgrade your Visual Basic 6 application to Visual Basic .NET. This chapter will address questions such as, What will my code look like after it has been upgraded? What types of projects are upgraded? How will my forms, classes, modules, controls, and ActiveX controls be upgraded? What happens when a component, property, method, event, or language statement can't be upgraded?
"It's your code."
"Just make it work."
All of your comments should be preserved and in the same place they were before the upgrade. If you include #If.Then directives, these will also be included in your upgraded project, and you should find them exactly where you put them, relative to everything else. The wizard tries to upgrade each element of your codelanguage statements, controls, components, and ActiveX referencesto the elements in Visual Basic .NET that most closely match.
If, for example, the MsgBox statement exists in both Visual Basic 6 and Visual Basic .NET, the wizard will upgrade your code to use MsgBox. If there is no direct match, the wizard finds a language statement or component that most closely matches the element you are using. For example, all references to a CommandButton Caption property in code are upgraded to the .NET Framework equivalent, Button.Text property. If no element in Visual Basic .NET represents the same element in Visual Basic 6, the code is left as is, an UPGRADE_ISSUE comment is inserted above the nonupgraded code, and an issue is logged to the upgrade report.
This goal fits hand in hand with the "It's your code" objective. The best way to guarantee that your application will run the same after upgrade is to upgrade the application to use language statements, controls, and objects that behave identically in both Visual Basic 6 and Visual Basic .NET. For example, the Upgrade Wizard could choose to replace all instances of the Microsoft ListView ActiveX control in your application with the .NET Framework ListView control, but it doesn't. The wizard doesn't make this upgrade because by reusing the exact same component, that componentand thus the applicationhas a better chance of behaving the same as before. If the wizard were to replace your 20 ActiveX controls with 20 noncompatible .NET Framework controls, you would spend more time changing code to run your application. You can get your application up and running more quickly when the upgraded code contains language statements, controls, and objects that are compatible and most familiar to you. Once you get the application running, you can choose to incrementally replace code or components with .NET equivalents, and then test each change as you go.
Figure 7-1 illustrates how the elements of a form are upgraded. Figure 7-2 illustrates how code is upgraded.
Figure 7-1 How a form is upgraded.
Figure 7-2 How code is upgraded.
The lack of support for certain features in Visual Basic .NETsuch as Dynamic Data Exchange (DDE) and ActiveX Documentsmeans that certain types of Visual Basic 6 applications aren't well suited to a Visual Basic .NET upgrade. These types of applications you can consider in the "out" category when it comes to upgrade. However, just because an application is in the "out" category doesn't necessarily mean that you can't use it in Visual Basic .NET. You might still be able to communicate with your Visual Basic 6 application from Visual Basic .NET without changing it. For example, rather than upgrading your ActiveX DLL project you may want to leave it as is. You can create a Visual Basic .NET application that interoperates with the existing ActiveX DLL.
By reusing existing ActiveX components in your Visual Basic .NET applications you can create the Visual Basic .NET applications more quickly. The general ability of Visual Basic .NET applications to communicate with ActiveX components is known as COM interop. You may want to take advantage of COM interop when upgrading your applications so that you don't need to upgrade the application and all of its COMgenerally known as ActiveXdependencies at once. See Chapter 9 for more information on using COM interop.
The Upgrade Wizard will either not upgrade or provide only partial support for the following items:
Where possible, the Upgrade Wizard will upgrade your Visual Basic 6 project to an equivalent project type in Visual Basic .NET, as shown in Table 7-1. Equivalent Visual Basic .NET project types exist for common project types such as Standard EXE, ActiveX DLL, and UserControl.
Table 7-1 Visual Basic 6 and Equivalent Visual Basic .NET Project Types
A Visual Basic 6 project contains a number of attributes, including Name, command- line arguments, conditional compilation constant settings, Help settings, version information, and compiler settings. Let's look at how the Upgrade Wizard handles each of these attributes.
Project name The project name for a Visual Basic 6 application is upgraded to be the Assembly Name and Root Namespace name for the Visual Basic .NET application. The Assembly Name is the name that other applications or tools use to load the EXE or DLL containing your project. The Root Namespace name is the name that other applications and tools use to refer to your Visual Basic .NET application or library. The Root Namespace name is roughly equivalent to the project name found in Visual Basic 6. Since the Visual Basic 6 project name is applied to your Visual Basic .NET project, anywhere in your code that you fully reference a type by prefacing it with the project name, the code will continue to work as is, without change.
Command-line arguments If you create a Visual Basic 6 EXE project that relies on command-line arguments, you can test your application in the Visual Basic 6 debugger by setting command-line arguments on the Make tab for Project Properties, as shown in Figure 7-3.
Figure 7-3 Visual Basic 6 command-line setting in the Project Properties dialog box.
The command-line settings aren't upgraded with your project. To edit them in Visual Basic .NET, select the project in the Solution Explorer, and then select Properties from the Project menu. Within the Properties dialog box, select Debugging under the Configuration Properties folder, as shown in Figure 7-4.
Figure 7-4 Visual Basic .NET command-line setting in Configuration Properties, Debugging.
Conditional compilation constant settings If you use #If.Then conditional statements in your code, you can set the value for the condition as a global project setting. In Visual Basic 6 the setting is located on the Make tab of the Project Properties dialog box, as shown in Figure 7-5.
Figure 7-5 Visual Basic 6 conditional compilation statement setting in the Project Properties dialog box.
The constant values that you set will be upgraded to Visual Basic .NET. To edit your settings, select the project in the Solution Explorer and then choose Properties from the Project menu. Within the Properties dialog box, select Build under the Configuration Properties folder, as shown in Figure 7-6.
Figure 7-6 Visual Basic .NET custom constants setting under Configuration Properties, Build.
Help settings In Visual Basic 6 you were allowed to have one Help file per project. You specify the Help file name on the General tab of the Project Properties dialog box, as shown in Figure 7-7. You could also set a project-level Help context ID.
Figure 7-7 Visual Basic 6 Help file setting in the Project Properties dialog box.
Creating Help to go along with your Visual Basic .NET application is different. A Visual Basic .NET application has no concept of a project-level Help file. Instead, you request Help on a per-form basis by including a HelpProvider component on each Windows Form that you want to support Help. Because no top-level Help file is associated with a Visual Basic .NET application, the Upgrade Wizard doesn't upgrade this project setting.
Version information The Upgrade Wizard upgrades most version information associated with your Visual Basic 6 application. As illustrated in Figure 7-8, the following attributes are available on the Make tab of the Visual Basic 6 Project Properties dialog box:
Figure 7-8 Visual Basic 6 version settings in the Project Properties dialog box.
The attributes are upgraded to a separate file in your project called AssemblyInfo.vb, which contains project-level attributes for your project. For example, after you upgrade a Visual Basic 6 project, the version-related attributes are set in the AssemblyInfo.vb file as follows:
<Assembly: AssemblyTitle("Wow! My upgraded application")>
Compiler settings The Upgrade Wizard doesn't upgrade any Visual Basic compiler options to Visual Basic .NET. Because the Visual Basic 6 and Visual Basic .NET compilers generate different types of instructions, the compiler options for each product have nothing in common. The native code optimization settings, such as Remove Array Bounds Checks, don't make sense for the Visual Basic .NET compiler. The Visual Basic .NET compiler is required to generate secure code. Therefore, you don't have the option of turning off certain safety checks, such as array bound checks; all safety checks need to be in place.
The filename of your Visual Basic 6 .vbp project file is applied to your new Visual Basic .NET .vbproj file. For example, if the name of your Visual Basic 6 project is MyProject.vbp, the name of your Visual Basic .NET project will be MyProject.vbproj.
Individual item filenames Each file contained within a Visual Basic 6 project retains the same base filename after upgrade. The file extension for all upgraded files is set to .vb. For example, if you have a form file in your project called Form1.frm, it will be upgraded to Form1.vb. What if you have two files with the same base filename, such as Main.frm and Main.bas? Since both files can't upgrade to the same filename (Main.vb, in this case), the Upgrade Wizard avoids the conflict by renaming one of the files with its internal name. For example, if the name of module Main.bas is modMain, the file will be renamed modMain.vb to avoid conflicting with the form file Main.vb.
Table 7-2 Mapping Between Visual Basic 6 Intrinsic Controls and .NET Windows Forms Controls
Layout and Design-Time Property Settings
The design-time layout and properties you set on a Visual Basic 6 form and the controls contained on the form are saved in a special section of the .frm file. The form and controls are saved in property description blocks, as illustrated in Figure 7-9.
Figure 7-9 Visual Basic 6 .frm file in text view.
Windows Forms stores layout and property settings differently. All settings are saved as part of your code in a hidden block called Windows Form Designer Generated Code. The design-time settings for a Windows form can be found in the InitializeComponent subroutine within this hidden block.
The Upgrade Wizard maps your Visual Basic 6 design-time settings to generated code in InitializeComponent. For example, suppose you have a Visual Basic form containing a button named MyButton, as shown in Figure 7-10. (You can find the MyButton.vbp project on the companion CD.)
Figure 7-10 Visual Basic 6 form with a button on it.
The Visual Basic .frm file for the form will contain this description:
Begin VB.Form Form1
If you upgrade the preceding Visual Basic .frm, the generated Visual Basic .NET code will be
Private Sub InitializeComponent()
Table 7-3 shows how the original .frm description and the generated Visual Basic .NET code match up line for line.
Table 7-3 Mapping Between Visual Basic 6 .frm Settings and Visual Basic .NET Code
After the form is upgraded, it will look nearly identical to its Visual Basic 6 counterpart, as shown in Figure 7-11.
Figure 7-11 Upgraded Visual Basic .NET form.
Let's take a look at some cases in which the design-time settings don't upgrade. We'll place a Data control on the Visual Basic 6 form with the MyButton control. We'll also set the UseMaskColor property of the MyButton control to True, resave the Visual Basic 6 application, and upgrade it again. The first issue is that the Data control (as listed in Table 7-2 on page 128) can't be upgraded. A red label on the form represents the Data control. Red labels on your form indicate that the form didn't fully upgrade.
An interesting characteristic of this upgraded project is that if you build it, you won't get any compiler errors. How can this be true if there is no property equivalent to the CommandButton's UseMaskColor property? If the Upgrade Wizard emitted the design-time property setting in the InitializeComponent section, it would lead to a compiler error. Any compiler errors that occur within InitializeComponent will prevent you from viewing the design-time form. Since it is important that you be able to view your form after upgrade, the wizard intentionally omits any design-time properties that don't map. Instead, it logs an error to the upgrade report.
If you open the _UpgradeReport.htm file included with your upgraded project, you'll see a summary of the properties that weren't upgraded for each control. In this example, you'd see an entry for the CommandButton's UseMaskColor property. Figure 7-12 shows the upgrade report that is produced. The report that documents the issue provides a link to Help, and, where possible, it offers suggestions on how to work around or solve the issue.
Figure 7-12 Visual Basic .NET upgrade report.
Control arrays are a long-standing Visual Basic feature. A control array allows several controls to share the same events and initial property settings, allowing you to apply the same behavior to the controls in the control array. You can also create control arrays in Visual Basic .NET. However, the way you do so is very different from the way you create them in Visual Basic 6. Think of a control array in Visual Basic .NET as a standard array containing controls. To create a control array in Visual Basic .NET, you need to write code to declare an array of the particular control type, and then add the controls to the array. You write additional code to hook the same set of events to each member of the control array. If you're dealing with a dozen or more control array elements on your form, writing all that code is a time-consuming process.
The Visual Basic .NET compatibility library introduced earlier in this chapter includes support for control arrays. The compatibility library contains an array class for each control type. For example, the control array class for Button is called ButtonArray. The control array class includes methods such as Item and Load that allow you to access control array elements or add new members to the control array. In addition the control array class includes all of the events for the underlying control. The events are shared for all elements of the Visual Basic .NET control array, as you would expect based on how Visual Basic 6 control arrays behave.
The Upgrade Wizard upgrades your Visual Basic 6 control arrays to target control array classes defined in the Visual Basic .NET compatibility library. Control arrays and all associated code are upgraded as is, with minor syntactical changes in some cases, as illustrated in the following example.
Consider a Visual Basic 6 form that has two command buttons in a control array called Command1. The following Visual Basic 6 code loads Command1(2) as a new control array element:
Private Sub Command1_Click(Index As Integer)
Here's the Visual Basic .NET code after the Upgrade Wizard has upgraded it:
Private Sub Command1_Click(ByVal eventSender As System.Object, _
Focus your attention on the usage of Command1, and ignore the pixel-to- twips conversions; you'll see that the code you need to use control arrays is nearly identical, with a couple of notable differences:
Despite these differences, the good news is that Visual Basic .NET and the Upgrade Wizard both support control arrays.
ADO Data Control
You can place the ActiveX ADO Data control (ADODC) shipping with Visual Basic 6 on a Windows form, but you can't use it to bind to Windows Forms controls. For example, you can't place an ADODC control on a Windows form and hook a TextBox up to it because the ADODC control has no way to communicate the bound data to the Windows Forms TextBox control. The ADODC control can communicate only with other ActiveX controls, not with .NET Windows Forms controls.
To resolve this issue, the Visual Basic .NET compatibility library contains a .NET version of the ADODC control. You can use the ADODC .NET control to bind data to Windows Forms controls and other ActiveX controls. The Upgrade Wizard automatically upgrades any instances of ADODC ActiveX controls to ADODC .NET controls. The ADODC .NET control was designed to be a compatible replacement for the ADODC ActiveX control.
How does this help you? If you use the ADODC ActiveX control in your Visual Basic 6 applications, you should expect your ADO data-bound applications to continue working after you upgrade to Visual Basic .NET.
Microsoft Data Binding Collection
The Visual Basic .NET compatibility library provides an MSBind .NET class as a compatible replacement for the ActiveX MSBind object found in Visual Basic 6.
Visual Basic 6 allows you to link a control such as a TextBox with the ADODC control by setting the DataSource property of the TextBox control. Although the DataSource property appears on the TextBox control, the property is added and managed by Visual Basic and not by the control itself. In fact the control does not even know that it has a DataSource property. When you set the DataSource property, Visual Basic creates an instance of MSBind and associates the TextBox with a field in a database. The database field is specified by the DataField property, which is also added to the TextBox control and managed by Visual Basic.
The problem is that Windows Forms doesn't provide any support for the DataSource and DataField properties. In fact, when you place a TextBox (or any other control) on a Windows form, you won't find a DataSource or DataField property. How do you get data binding to work in Visual Basic .NET? You use an instance of a binding collection (MSBind).
You can add items to the binding collection to associate a property on a control with a field in a database. To bind a control's property to a field in a database, you add the control and the property where you want the database data to be stored to the MSBind collection. If you want to implement custom data binding or binding to nontraditional properties on a control, use MSBind in your Visual Basic 6 application.
Because there is no DataSource or DataField property, the Upgrade Wizard translates the binding information stored in the DataSource and DataField properties to binding information set into an MSBind .NET binding collection. Suppose you're upgrading an application with a TextBox (Text1) bound to an ADODC (Adodc1) control. The TextBox displays the CompanyName contained in the Customers table. The Upgrade Wizard automatically generates the following code to hook up data binding:
Private ADOBind_Adodc1 As VB6.MBindingCollection
VB6_AddADODataBinding is called from Sub New so that the data bindings are set up as soon as the form is created. VB6_RemoveADODataBinding is called when the form is disposed. Data bindings are removed when the form is destroyed.
In general, if you have an ADODC-based data-bound application in which all the data binding is set up at design time, the Upgrade Wizard takes care of generating the necessary Visual Basic .NET code to make it work. Because there are no properties you can set in the Property Browser, updating the application after upgrade requires considerably more work. You'll need to update VB6_AddADODataBinding to add or remove bound controls and associated database fields.
The Upgrade Wizard treats the SSTab control as a special case because the SSTab ActiveX control requires a special interface called ISimpleFrame. This interface enables the control to contain other controls. Without this interface, you can't place other controls within the SSTab. If you've used the SSTab control, you know that it would be pretty useless if you couldn't place other controls inside it. The control reaches the height of uselessness when you place it on a Windows form. Windows Forms doesn't support the ISimpleFrame interface, so you can't place any controls on the tabs within the SSTab.
The Upgrade Wizard recognizes this situation and rectifies it by automatically upgrading your instances of SSTab controls to instances of Windows Forms TabControls. The Windows Forms TabControl is similarbut not identicalin behavior to the SSTab control. You'll find that after upgrade, the TabControl has a similar appearance to the SSTab control. All the controls contained in the SSTab control will be found on their respective tabs in the Windows Forms TabControl. However, you'll notice differences when you write code to operate the TabControl. Most of these differences stem from the TabControl having a TabPage collection object. You need to manually update the code that sets array properties, such as TabCaption, to instead set the caption on the specific tab within the TabPage collection.
The UpDown control uses internal interfaces supported by Visual Basic 6 to buddy up with another control. These interfaces aren't supported in Windows Forms. Furthermore, because the control is an ActiveX component, it can't link to a non- ActiveX component such as a Windows Forms Button control. If you place an ActiveX UpDown control on a Windows form, you should set the BuddyControl property to another control on the form, and then run the application. The UpDown control doesn't update the buddy control.
The Upgrade Wizard won't upgrade UpDown controls found on a form. Instead, you must replace each UpDown control with the Windows Forms NumericUpDown control.
General Types of Code Conversions
The Upgrade Wizard upgrades your Visual Basic 6 language statements using a variety of means, which are explained in the following sections.
Mapping to native language statement with the same name Most Visual Basic core language statements, such as If.Then, For.Next, Select Case, And, Or, Do.Loop, On Error GoTo, and MsgBox fall into this category. The code you see in Visual Basic 6 is the code you get in Visual Basic .NET.
Mapping to native language statement with a different name The functions IsEmpty, IsNothing, and IsObject fall into this category. Each of these functions operates on Variants, which aren't supported in Visual Basic .NET. These functions are upgraded to functions that operate on Object types. The following Visual Basic 6 code:
Dim b As Boolean
upgrades to the following Visual Basic .NET code:
Dim b As Boolean
Mapping with coercion Visual Basic .NET disallows direct assignments of incompatible types to each other without an explicit conversion. For example, you can't directly assign an integer a String value or a Date to a Double. You need to do an explicit conversion using a function such as CInt or CShort. Some types contain conversion methods, such as ToString or ToOADate. As an example of how conversion functions are added after upgrade, consider the following Visual Basic 6 code:
Dim i As Integer
This code upgrades to the following Visual Basic .NET code:
Dim i As Short
Mapping to an equivalent .NET Framework function Math functions such as Abs, Atn, Cos, and Sqrt fall into this category. Certain properties on the App object, such as PrevInstance, upgrade to .NET equivalents as well. For example, take a look at the following Visual Basic 6 code:
Dim i As Integer
This code upgrades to the following Visual Basic .NET code, using the equivalent function from the System.Math class:
Dim i As Short
Mapping to a function provided by the Visual Basic .NET compatibility library The LoadResString, LoadResData, LoadResPicture, SendKeys, and some App object methods fall into this category. The following Visual Basic 6 code:
Dim strPath As String
Dim strPath As String
No mapping available This category includes cases that can't be automatically upgraded. Instead, the wizard generates an upgrade issue and possibly an UPGRADE_TODO item. The binary string functions, such as AscB, LeftB, MidB, and RightB fall into this category. For example, the following Visual Basic 6 code:
Dim iCharCode As Integer
upgrades to the following Visual Basic .NET code:
Dim iCharCode As Short
Several UPGRADE_ messages are emitted in this case. The UPGRADE_ISSUE messages relate to byte-related support not being available. The UPGRADE_TODO message warns you that the .NET conversion function used might not have the behavior you desire.
Option Explicit On Included Automatically
When you use the Option Explicit statement in Visual Basic 6, the compiler forces you to declare all variables with a Dim, Private, Public, or Static statement (for example). If you're not using the Option Explicit statement in Visual Basic 6, the Upgrade Wizard includes the Option Explicit On statement in all forms and modules and takes care of declaring any undeclared variables for you. If you've been planning to go through and explicitly declare all of your variables, or you've avoided doing it because of time constraints, your wait has been rewarded. The Upgrade Wizard takes care of this for you.
DefType Is Upgraded
If you use the DefType statement to determine the variable type for unqualified variable declarations, your DefType declarations will be upgraded to the appropriate type. For example, the following Visual Basic 6 code:
DefStr A-Z 'All unqualified variable declarations will be Strings
upgrades to the following Visual Basic .NET code:
Data Types Are Upgraded to Fit
The storage size for Visual Basic intrinsic types such as Integer and Long has changed in Visual Basic .NET. In Visual Basic 6 an Integer is 16 bits and a Long is 32 bits. In Visual Basic .NET an Integer is 32 bits and a Long is 64 bits. Most of the time it doesn't matter whether you use an Integer instead of a Long. If you have a loop index that goes from 0 to 10, you can nitpick over the performance implications of using one size or another, but generally it makes no difference. The program works the same way.
Sometimes, however, the size difference matters. For example, if you're calling Windows API functions that require a 32-bit integer argument, you had better use a Declare statement that declares the argument as 32 bits.
To keep your application running smoothly after upgrade, the Upgrade Wizard declares all of your numeric types to use the correct Visual Basic .NET equivalent based on size. This means that an Integer variable is upgraded to Short. A variable of type Long is upgraded to type Integer. In the case of the Variant type, the Upgrade Wizard maps to the closest equivalent type found in Visual Basic .NET: Object. Table 7-4 gives a mapping of types between Visual Basic 6 and Visual Basic .NET. The table provides mappings where the name of the type is different between Visual Basic 6 and Visual Basic .NET. All other types, such as Byte, Single, Double, and String, map as is.
Table 7-4 Mapping of Types Between Visual Basic 6 and Visual Basic .NET
ByRef Added to Unqualified Parameters
The default calling convention in Visual Basic 6 is to pass all unqualified parameters as ByRef. Visual Basic .NET, on the other hand, requires you to qualify all parameters as ByVal or ByRef. Because the Visual Basic 6 default calling convention is ByRef, the Upgrade Wizard upgrades and qualifies all unqualified parameters with the ByRef keyword.
For example, the following Visual Basic 6 code:
Sub Test(MyParam As Long)
upgrades to the following Visual Basic .NET code:
Sub Test(ByRef MyParam As Integer)
Code-behind forms refers to code that makes reference to a form, control, property, method, or event. Although this is normally code you write behind a form, you can also reference controls from other project items, such as a class module or .bas module. We will limit this discussion to code that references a property, method, or event for any form or control in the project.
Code that references a form or control property is upgraded in a similar fashion to a design-time property setting, as discussed earlier in the section "Layout and Design-Time Property Settings." The main difference is that for properties you refer to in code, the Upgrade Wizard will leave any code that cannot be upgraded as is. In many cases this will lead to a compiler error. In addition, a comment that begins with UPGRADE_ (such as UPGRADE_ISSUE) will be inserted on the line immediately above the nontranslated statement. For example, let's say you attempt to upgrade the following code:
cmdMyButton.UseMaskColor = True
The upgraded code will appear as follows:
'UPGRADE_ISSUE: CommandButton property cmdMyButton.UseMaskColor
The Upgrade Wizard leaves the code in as iswithout omitting it or commenting it outbecause doing so makes the issue stand out like a sore thumb. You are forced to recognize and deal with the problem before you can run your upgraded application. The philosophy here is that it's best to get all the bad news up front. It's generally much easier to resolve a problem as soon as you discover it, rather than finding it down the road after you've made a bunch of code changes. If the Upgrade Wizard were simply to emit the UPGRADE_ISSUE command and avoid the compiler error by commenting out the offending line, you might never pay attention to the issue. If a problem related to the issue surfaced months later, you might end up spending a significant amount of time tracking down the line of code that the Upgrade Wizard conveniently commented out for you.
Table 7-5 Class Attribute Mappings
Persistable Classes: ReadProperties, WriteProperties
The ReadProperties and WriteProperties events for persistable classes and user controls are not upgraded because the .NET Framework doesn't support the same notion of data persistence that ActiveX supports. The .NET Framework requires that clients of a .NET server persist the properties of the server by generating code to set server properties to initial property values. Clients persist ActiveX servers, on the other hand, by passing either a PropertyBag or a binary stream to the ActiveX server, requesting that the server save the state of its properties to the PropertyBag or stream. When the server is a Visual Basic-authored ActiveX component, the client will invoke the ReadProperties and WriteProperties events of the component. After the server has been upgraded to a .NET server, the client directly obtains the property values for the ActiveX component without invoking events such as ReadProperties and WriteProperties.
The bottom line is that you don't need ReadProperties and WriteProperties to create a persistable Visual Basic .NET server class. You can remove this code after upgrade.
For a Visual Basic 6 class in which the DataSourceBehavior property is set to vbDataSource, the class is upgraded to implement the DataSource interface. Your code contained within the GetDataMember event is upgraded to the GetDataMember method of the implemented DataSource interface. You can test your upgraded class by assigning an instance of it to the DataSource property of a control such as the Visual Basic 6 DataGrid. The DataGrid should display the data returned by your upgraded Visual Basic .NET DataSource class.
To support data binding, any Microsoft ADODC ActiveX controls you use will automatically be upgraded to use a .NET ADODC control. The .NET version is designed to be compatible with the ActiveX version.
Visual Basic 6 provides internal support for DAO and RDO data binding. There are neither internal supports nor public classes in Visual Basic .NET to support DAO or RDO data binding. If your application requires data binding, you should manually replace your DAO- or RDO-related elements with ADO-related elements. You can make the changes to your Visual Basic 6 application, test the changes, then upgrade your ADO-based Visual Basic 6 application to Visual Basic .NET.
If you use a DataEnvironment designer in your Visual Basic 6 application, the wizard will create a Visual Basic .NET DataEnvironment classcontained in its own .vb fileand add it to your upgraded Visual Basic .NET project. The DataEnvironment class will contain all settings and objects found in the original Visual Basic 6 DataEnvironment. Any code that references the DataEnvironment will continue to work. You should be able to get your upgraded application to work with the generated DataEnvironment class at run time.
Visual Basic .NET doesn't provide a way for you to edit DataEnvironment properties at design time. To change property settings, you need to edit the code contained in the generated DataEnvironment class file.
In some cases the code and design-time settings related to a designer are upgraded to work in the upgraded Visual Basic .NET application. For example, code associated with your WebClass is upgraded to Web Forms; DataEnvironment-related settings and code are upgraded to a generated DataEnvironment class. The CrystalReports package in Visual Studio .NET supports reading reports stored in DataReport designer format.
If, on the other hand, your application is a more typical three-tier application with a presentation layer that communicates with a server component, it's most definitely in the in category. You'll find that the Upgrade Wizard does a good job of upgrading applications that fall into this category. The Upgrade Wizard will strive to upgrade your application in the least intrusive way possible that will allow you to get it up and running quickly. Using the Upgrade Wizard, you will be able to get your Visual Basic 6 application up and running in Visual Basic .NET more quickly than by porting your Visual Basic 6 application by hand.