VB6 is more forgiving than VB.NET or C# in what names can be used for variables, classes, and class members. For example, VB6 allows you to define a global variable whose name matches the name of a class defined elsewhere in the application. When you convert the VB6 application, however, the VB.NET code can’t be compiled because of an error that reads
'name' is a type and can't be used as an expression.
A similar problem occurs when a class exposes both an event and a property with same name. VB6 supports and correctly resolves this name clashing, while VB.NET and C# generate a compilation error that reads
'name' is already declared as 'membername' in this class,”
VB Migration Partner works around the latter issue for built-in VB6 controls by appropriately renaming the one of the members. For example, the DTPicker control has both a property and an event named Format, thus VB Migration Partner renames the event as FormatEvent6.
VB Migration Partner is able to detect if a class exposes two members with same name – for example, a method and an event both named Parse – and renames the method accordingly (in this case, the method would be renamed as Parse_Renamed).
In the most general case, however, VB Migration Partner isn’t able to automatically solve issues of this kind, therefore you must rename one of the VB6 members during the migration to VB.NET. The easiest way to accomplish this step is by means of the SetName pragma, which you can use at the project, file, method, or variable level. For example, let’s suppose that you have both a class and a global variable named Widget. The easiest workaround in this case is to change the class name to something else, for example WidgetInfo, which you can achieve by means this pragma inside the Widget.cls file:
This workaround is especially useful for class and form names.
You can also use the SetName pragma to generate a name that is more readable then the method_Renamed name that VB Migration Partner generates when it detects a name collision.
There is one case, however, that VB Migration Partner isn’t able to fix, not even with the aid of SetName pragma. This problem occurs when a control and its parent form have the same name, clearly a case of bad VB6 programming practice. The only solution in this case is manually renaming either the form or the control in the VB6 project.