Severe Warning InformationEnterprise Edition only
The VB.NET Compatibility Check feature offers close to 50 rules to report VB.NET compatibility issues in VB6 code. Use the rules to prepare existing code for migration and to evaluate the migration work required. A typical compatibility issue cannot be resolved by a computer. Human attention is required. Therefore, you need to get prepared for manual work.
The rules are for upgrading code from Visual Basic 6.0 to Visual Studio 2008 Professional Edition, official release version. The free download Microsoft Visual Basic Power Packs v3.0 is also good to have at the time of upgrading, even though this is not an absolute requirement.
To upgrade to VB.NET newer than 2008, one can use the 2008 wizard, then load the resulting project in a newer version of Visual Studio. The rules are also useful for migrating from VB6 to the older versions of VB.NET (2002/2003/2005). The older upgrade wizards perform somewhat less perfectly, however, so you should be prepared for additional compatibility issues. Most notably, it is not possible to upgrade UserControls to VB.NET 2002.
Select <VB.NET Compatibility> or <VB.NET Fix before upgrade> as the problem filter in Problem options to enable the VB.NET compatibility rules. You can also prepare your own filter to focus on a smaller group of issues.
Tip. In addition to reviewing these problem types, we recommend that you remove dead code and run find duplicate code before attempting the upgrade. This may yield a considerable reduction in the amount of work required.
Severe Warning InformationAll of the following problems require the Enterprise Edition to function. They are also enabled in the demo and Standard/Pro Editions when you analyze max 10 source files.
Add-in model changed in VB.NET. This is a VB add-in project. The add-in programming model has changed in VB.NET, requiring major migration work. Feature not upgradable.
ADO required for data binding in VB.NET. Data controls can be bound only to ADO, not to RDO or DAO. Upgrade the RDO and DAO data binding to ADO before upgrading your project to VB.NET. See vb6 help or MSDN for topic 'RDO to ADO' or 'DAO to ADO'. Fix required before upgrade.
Array must start at 0 in VB.NET. VB.NET requires arrays be declared with a lower bound of zero. Non-zero-based arrays will be upgraded to be zero-based. A replacement format is available, allowing non-zero lower bounds, but it is slower than native arrays, and limited when passing arrays as parameter to functions. Use of zero-based arrays is recommended. Arrays with negative bounds are especially problematic, as all .NET arrays are in the range 0..ubound. Arrays with a negative upper bound are not upgraded at all. Can be fixed before or after upgrade.
As Any not allowed in VB.NET. As Any will not be allowed in API declarations. Get prepared by adding a separate API declaration for all parameter types you may need. Can be fixed before or after upgrade.
As New doesn't auto-instantiate if object released in VB.NET. VB.NET does not automatically re-instatiate an object that has been explicitly released. This problem affects you only if you set this variable to Nothing and try to use it later without instantiating a new object first. Can be fixed before or after upgrade.
As New unsupported for arrays in VB.NET. Arrays cannot be declared with 'As New'. You will need to remove the New keyword and initialize the array before use. Can be fixed before or after upgrade.
ByRef property params unsupported by VB.NET. VB.NET does not support ByRef property parameters, because they can lead to unexpected behavior. All declarations of parameterized properties must specify ByVal for the parameters. The .NET upgrade wizard turns all ByRef parameters into ByVal without warning. Fix recommended before upgrade.
ByVal/ByRef not allowed in API calls in VB.NET. ByVal or ByRef will not be available for calling the API. Review your API declaration to find out if you can replace it by a better declaration where ByVal/ByRef is not needed to call. Can be fixed before or after upgrade.
Class Instancing changes in VB.NET. There is no direct equivalent for the following Instancing property values: 3=SingleUse, 4=GlobalSingleUse, 6=GlobalMultiUse. The upgrade wizard sets the access level to Public. You can control the way that an object can be created by setting the access level of the constructor (Sub New). The unavailability of the Instancing value may require changes in the way the class is being used. Work required after upgrade.
COM method not callable from VB.NET. VB.NET projects can call COM class methods but not COM module methods. You may be able use the .NET framework classes to achieve the same functionality or you may need to keep your code in VB6. This problem detection rule requires that the corresponding COM file has been analyzed. Work required after upgrade.
COM+/MTS not upgradable to VB.NET. The project refers COMSVCS.DLL (COM+ Services Type Library). Existing code will need to be upgraded to use .NET transaction processing. Work required after upgrade.
Conditional block excluded. A conditional compilation block (#If..#ElseIf..#Else..#End) is excluded due to a False condition. The VB.NET upgrade wizard doesn't migrate code inside a False branch. It copies the code 'as is'. If the False branch is large, it is recommended that you temporarily set the condition it to True before migration. Otherwise you will have to migrate it manually. Fix recommended before upgrade.
Control unsupported by VB.NET. A control type is not available in VB.NET. Image is auto-replaced by PictureBox. OLE Containers can be manually replaced by a browser control. MSComCtl2.UpDown won't upgrade but can be manually replaced by DomainUpDown or NumericUpDown controls. Work required after upgrade.
DDE unsupported by VB.NET. DDE is not available in VB.NET. You will have to use other kind of inter-process communication. Work required after upgrade.
Diagonal line unsupported by VB.NET. VB.NET does not support diagonal Line controls. After migration, you will have to override the OnPaint event to draw the line. It won't pay off to do it before migration, because the drawing statements change too. Work required after upgrade.
DoEvents() returns no value in VB.NET. DoEvents() does not return the number of open forms, or any other value. There will be no replacement function. The DoEvents statement will remain. Can be fixed before or after upgrade.
Drag-and-drop requires rewrite for VB.NET. VB.NET supports drag-and-drop functionality, but the object model is quite different. Drag-and-drop code must be rewritten. Work required after upgrade.
Event behavior changes in VB.NET. The behavior of this event will change somewhat in VB.NET. You will have to review and test the event code after migration. Affected events: ComboBox_Change, ComboBox_Scroll, ListBox_Scroll, Form_Activate, Form_DeActivate, Form_Terminate, Form_Unload, Class_Terminate. This problem is not reported for empty event handlers. Work required after upgrade.
Event log model differs in VB.NET. The event log model is different in VB.NET and manual work is needed. Affected code: LogMode, LogPath, StartLogging, StartMode. Work required after upgrade.
Initialized arrays in UDTs unsupported by VB.NET. Fields in user-defined types cannot be initialized arrays in VB.NET. Only arrays declared without dimension - MyArray() - are allowed. You must add code to ReDim array fields before use. Can be fixed before or after upgrade.
MDIForm event unsupported in VB.NET. The following events are unavailable: MDIForm_Click, MDIForm_MouseDown, MDIForm_MouseMove, MDIForm_MouseUp. There is no replacement. This problem is not reported for empty event handlers. Work required after upgrade.
Member cannot be default in VB.NET. Variables, Subs and Functions are not allowed as default members of objects in VB.NET. VB.NET upgrade wizard adds the member name automatically if you have typed your object variables and thus used early binding. If you use late binding (As Object, As Variant), you will have to add the name manually. You may prepare for migration by marking this member as non-default and fixing all references by hand. Fix recommended before upgrade.
Module not upgradable to VB.NET. This module type is not available in VB.NET. DHTML pages: stay in VB6. DataReports: unable to migrate. If your application depends heavily on property pages, it should be left in Visual Basic 6.0. ActiveX documents should either be rewritten as UserControls or left in VB6. Feature not upgradable.
Old VB project not upgradable to VB.NET. This project was made in VB version 3 or 4. VB.NET will not load it. You will need to upgrade to VB6 first. Feature not upgradable.
OLE Automation unavailable in VB.NET. The OLE Automation features are unavailable in VB.NET. You will need to use another kind of inter-process communication. Affected code: OleRequestPendingMsgText, OleRequestPendingMsgTitle, OleRequestPendingTimeout, OleServerBusyMsgText, OleServerBusyMsgTitle, OleServerBusyRaiseError, OleServerBusyTimeout. Feature not upgradable.
ParamArray is ByVal in VB.NET. ParamArrays are ByRef in classic VB, but they will be converted to ByVal for VB.NET. Your code seems to use ParamArray as an 'out' parameter to return values to callers. This is not possible in VB.NET. You should return 'out' values in the function return value (recommended) or in a regular ByRef array parameter (worse alternative). This problem rule does not fire for ParamArrays that do not return an 'out' value. Fix recommended before upgrade.
Parameterless default properties unsupported in VB.NET. A property with no parameters can't be the default member of an object in VB.NET. This means that you can no longer omit the property name to access the property. VB.NET upgrade wizard adds the property name automatically if you have typed your object variables and thus used early binding. If you use late binding (As Object, As Variant), you will have to add the name manually. You may prepare for migration by marking this property as non-default and fixing all references by hand. Fix recommended before upgrade.
Property mixes scopes. Property accessors have different levels of accessibility. This causes a problem when upgrading to VB.NET, because the upgrade wizard will convert all accessors to the widest scope, exposing previously hidden code. VB 2002 and 2003 require property accessors to have the same scope. VB 2005 and VB 2008 support different scopes for Get and Set, but the upgrade wizards in VB 2005 and VB 2008 do not: they still upgrade to the widest scope. Can be fixed before or after upgrade.
Property passed ByRef. A property is being passed to a ByRef parameter in a procedure call. In VB6, the changes to the parameter are not updated to the property. Thus, only Property Get executes. In VB.NET, updates are copied to the property when the call exits (copy in/copy out semantics). Thus, both Property Get and Set execute. This may lead to an unexpected change in the property value and a bug that is hard to detect. You should enclose the property in parentheses, which enforces pass ByVal instead of ByRef. Alternatively you can change the formal parameter to ByVal (if that preserves the logic during other calls to the same procedure). Fix recommended before upgrade.
Resource file requires work in VB.NET. The .NET resource file format is .resX. Code that loads resources (LoadResString, LoadResData, LoadResPicture) is converted automatically by the upgrade wizard, but the resource file itself is not. Work required after upgrade.
ScaleMode must be vbTwips for VB.NET. To make sure your forms upgrade correctly, always use ScaleMode=vbTwips. VB.NET transforms your forms coordinates from twips to pixels. If ScaleMode is non-twips, you'll have sizing issues. Fix recommended before upgrade.
Setting .Interval does not enable/disable timer in VB.NET. Setting Timer.Interval=0 does not disable the Timer (in fact, the interval will become 1 msec). You will have to use Timer.Enabled=False. Setting Timer.Interval>0 does not enable it either, you will need to call Timer.Enabled=True. Work required after upgrade.
String byte functions unavailable in VB.NET. The byte versions of string handling functions are not available in VB.NET. Encoding and decoding functions in the System.Text namespace replace this functionality. The upgrade wizard does not automatically convert the byte functions. You may want to consider replacing them with the Unicode (wide) functions before upgrading. Affected functions: AscB, LenB, InStrB, ChrB, LeftB, MidB, RightB, InputB Can be fixed before or after upgrade.
Sub Main not executed in VB.NET. The startup object is Sub Main. In VB.NET, Sub Main is not executed at all in this kind of a project. Work required after upgrade.
Sub Main: VB.NET program exits at End Sub. The startup object is Sub Main. Currently, the program exits when all objects are destroyed. In VB.NET, the program exits at end of Sub Main. Fix: Set a form to be the startup object. Call Sub Main from Form_Load event. Work required after upgrade.
TTF/OTF fonts required by VB.NET. If your application uses other fonts than TTF or OTF, these fonts will be changed to the system's default font, and all formatting (size, bold, italic, underline) will be lost. This applies to the default VB6 font MS Sans Serif. You might want to change all fonts before migration. Fix recommended before upgrade.
Type unsupported by VB.NET. Fixed-length string and Currency are not available as data types in VB.NET. VB.NET will auto-convert Currency to Decimal, which has more precision. VB.NET has a replacement for fixed-length strings, but it is slow and limited. Arrays of fixed length string are not allowed at all. It is recommended to change all fixed-length strings to variable-length strings. Can be fixed before or after upgrade.
Unavailable in VB.NET. The function or constant, or a direct replacement, is not available in VB.NET. Affected code: CVErr, GoSub, Return, vbDataObject, vbUnicode, vbFromUnicode, vbDefaultButton4, vbDatabaseCompare, VarPtr, StrPtr, ObjPtr, VarPtrArray, VarPtrStringArray. In addition, LSet will have a replacement for strings, but not for UDTs. IsEmpty will be upgraded to IsNothing, which can cause a subtle bug because IsEmpty(vbNullString)=False will be upgraded to IsNothing(Nothing)=True. Can be fixed before or after upgrade.
Underscore _names not hidden in VB.NET. Underscore as the leftmost character does not mean 'hidden'. There is a new syntax for marking items as hidden in VB.NET IDE. Work required after upgrade.
VB5 project may not upgrade to VB.NET. This project was made in VB5. You may be able to load it in VB.NET, but expect trouble. You might wish to upgrade it to VB6 first. Fix required before upgrade.
WebClasses upgrade to ASP.NET. You can upgrade Visual Basic 6.0 WebClass projects to ASP.NET Web Applications. Work required after upgrade.
The following style rules are also helpful when considering the .NET upgrade. These rules are available in all editions of Project Analyzer.
Variable/function missing type declaration. A variable does not have a defined data type. By default, the type is Variant in classic VB and Object in VB.NET. These generic types need more memory than other types. Decide what type you need and write it to the declaration. Upgrading to VB.NET will be easier if you use explicit data types. In VB.NET, you can set Option Strict On to require explicit data types.
Option Explicit missing. A file is missing its Option Explicit statement. You should always use Option Explicit. Using it makes VB require declaration of all variables. This way you avoid using unnecessary implicit Variants. Even better, you get rid of some nasty errors caused by typing errors and variables with similar names. The use of Option Explicit will also help in upgrading code to VB.NET. By forcing explicit variable declaration you prevent accidental use of late binding, which is harder to upgrade. Fix recommended before upgrade.
Optional parameter missing default value. Optional parameters should declare an explicit default value so that users will know what to expect when omitting the parameter. If you upgrade to VB.NET, the migration wizard will add a default value. The default for Variant parameters will be Nothing, not Missing, which can make your code behave differently. Can be fixed before or after upgrade.
Variable/Parameter with generic type. A variable or parameter is declared as a generic type. While this is completely legal, it may lead to slow and error-prone code. VB may have to use 'late binding' because it doesn't know what kind of object to expect. In late binding, calls to the object's members are slower and may result in a run-time error if the member doesn't exist. If you know what kind of an object the variable will contain, declare it as that type. This is especially important if you plan to migrate existing VB 3-6 code to VB.NET. The .NET upgrade wizard cannot successfully convert all late-bound calls, resulting in manual work and errors. Fix recommended before upgrade.
Project Analyzer Enterprise Edition does not check for all incompatibilities between VB6 and VB.NET. It provides a limited set of compatibility checks. When you upgrade to VB.NET, you are likely to find more incompatibilities. We recommended that you try to migrate your code to VB.NET to learn the process. Then you can return to VB6 and run Project Analyzer to begin your upgrade work with the VB6 code.