Troubleshooting Applications Upgraded from Visual Basic 6.0
Although the upgrading tools in Visual Basic .NET were carefully designed to detect and report any issues with upgraded applications, there are some cases that cannot possibly be detected. This topic lists some known issues that are not detected by the upgrading tools and explains how to address them.
Note Additional troubleshooting issues are addressed in a Knowledge Base article that will be updated as new issues are discovered. The article number is Q295626, available at Microsoft Product Support Services (http://support.microsoft.com/directory/content.asp?ID=FH;EN-US;vbdnmig).
Cannot Access Help Links After Upgrading Visual Studio .NET
When working with an application upgraded with an earlier version of Visual Studio .NET, the Help links inserted by the upgrade tool may cause a "Page not found" error. This occurs because the links reference the Help collection for the earlier version, and that Help collection was uninstalled.
To fix this problem, use the Find and Replace command on the Edit menu to search for the string "MS.VSCC" and replace it with "MS.VSCC.<VersionNumber>" (for example, "MS.VSCC.2003" for Visual Studio .NET 2003) in all of the Help links.
Behavioral Difference for Fixed-length Strings in User-defined Types
In Visual Basic 6.0, strings assigned to a fixed-length string in a user-defined type were automatically truncated if they were longer than the fixed length. After upgrading to Visual Basic .NET, strings will no longer be truncated, possibly resulting in incorrect results.
Note During upgrade, the VBFixedString attribute is added to fixed-length strings in user-defined types. This attribute allows the file functions in the Visual Basic Compatibility library to treat them as fixed-length strings.
To fix this problem, find any code that assigns a string to the fixed-length string and add code to check the length of the string and truncate it if necessary:
' Before MyString = "1234567" MyStruct.FixedString5 = MyString ' After MyString = "1234567" If Len(MyString) > 5 Then MyString = Microsoft.VisualBasic.Left(MyString, 5) End If MyStruct.FixedString5 = MyString
Closing a Form Calls Dispose
In Visual Basic 6.0, you could unload a form and later reload it by calling the Show method. In Visual Basic .NET, the Close method for a form calls the Dispose method so that it is automatically garbage-collected. This can cause subtle behavioral differences that may be hard to detect.
- In Visual Basic .NET, if you call the Show method for a form that has been unloaded, you will get a new instance of the form; any property settings from the base class will be lost.
- For forms that are shown modally, Dispose is not called automatically. In some cases, you may want to call Dispose in order to clean up resources.
Late-bound Calls to COM Objects May Cause Type Mismatch Errors
In Visual Basic 6.0, when a late-bound COM object was passed as a parameter to a late-bound call, the object was coerced to a Variant of type Nothing. When upgraded to Visual Basic .NET, COM objects declared as type Object are treated the same as Variants (which are always converted to type Object during upgrade); these objects are marshaled to the variant type Empty. This causes a type mismatch error in Visual Basic .NET.
To fix this problem, make sure that all objects are early bound.
Values Returned by Err.Number May Be Different
In some cases, errors returned by Visual Basic .NET may be different than those returned by Visual Basic 6.0. For error handling code that relied on the values returned by Err.Number, this might cause different behavior in your application.
The following code shows an example of this:
' Visual Basic 6.0 On Local Error GoTo Result Dim x() As Boolean Dim y As Variant y = x(10) Result: If Err.Number = 9 Then ' Do something. Else ' Do something else. End If
Before upgrading, Err.Number will always return 9 (Subscript out of range) and execute the first part of the If statement. After upgrading, it will return 91 (Object variable or With block not set) and execute the Else clause. This is because in Visual Basic .NET, an array must be initialized before it can be referenced; in Visual Basic 6.0, arrays were initialized when declared.
If you depend on the return values from Err.Number in your code, you should carefully test the results and modify your code as necessary.
Dispose Must Be Explicitly Called for a DataEnvironment
In Visual Basic 6.0, any open recordsets and connections were closed when a DataEnvironment was closed. When upgraded to Visual Basic .NET, the DataEnvironment becomes a Public member of the DataEnvironment class; recordsets and connections are not automatically closed.
You will need to add code to explicitly close the recordsets and connections by calling the DataEnvironment.Dispose method. For Windows Forms applications you can call the Dispose method from the startup form's Dispose method. For class libraries, you will need to implement a Dispose method on your class library then have the client application call Dispose before it releases it's reference to the class.