VBUC Documentation | Mobilize.Net
Mobilize.NetForumsBlogDocumentation Home
  • Mobilize.Net VBUC
  • Introduction
  • Install and Licenses
  • Get Started
  • Migration Guide
  • VBUC Features
  • Mappings Grammar
  • Generated Code
  • Upgrade Options
    • Data Access
    • Grids
    • Microsoft
    • Sheridan
    • Others
    • Code Conversion
    • C# Features
  • Third-party controls
  • Best Practices
  • EWIs
    • Warnings
    • Issues
    • ToDos
    • Notes
  • Issues and Troubleshooting
    • Microsoft.VisualBasic Uses
    • Safe and Unsafe Methods Layer
    • Third Party Components
    • Migration Process
    • Classic ADO Conversion to ADO.NET
    • VB6 and .NET integer division
    • VB6 On Error Statements
    • Running a .NET Core application in a machine with no Visual Studio installed
    • Databases issues
    • Unsupported assemblies on .NET Core and .NET 5
    • Icon Extraction Issues
    • HTTPS sites are not loaded in Windows XP
    • Short-Circuit Boolean Logic in C#
    • Assessment Report Issue
  • Knowledge Base
    • FAQ
      • Does the VBUC support the Sheridan VB 6.0 controls suit?
      • How effective is the Visual Basic Upgrade Companion tool at converting an application's front end?
      • What controls does the Visual Basic Upgrade Companion tool supports?
      • How does the VBUC handle VB6 Collections?
      • Can the VBUC migrate intrinsic VB6 functions and libraries?
      • Where is the source code for the support (helper) classes used by the VBUC?
      • How does the VBUC convert ADO to ADO.NET?
      • Can the Visual Basic Upgrade Companion tool be customized?
      • What are Stubs?
    • How-To
      • App.Config and Database Access
      • Avoid reflection in Hot Paths
      • Convert ESRI ArcGIS Visual Basic 6.0 applications to .NET
      • Drag and Drop Conversion Steps
      • Inserting elements in a ListView
      • String vs StringBuilder
      • Word Automation in VB6 vs .NET
      • Configure default Factory Database provider
      • GetPrivateProfileString Windows API working in migrated code
      • Upgrade projects with shared files
  • Release Notes
Powered by GitBook
On this page
  • Working with EWIs
  • Steps to fix a migration issue
  • EWIs Lists

Was this helpful?

EWIs

The following section provides useful information about the messages (comments) that will appear on your upgraded code and how to solve them.

PreviousBest PracticesNextWarnings

Last updated 1 year ago

Was this helpful?

Working with EWIs

The number of in your code depends entirely on your programming style and the size, type and complexity of files that you want to upgrade. As a general rule, forms usually have more issues than classes and modules, because forms have a richer object model and significant transformations must be applied when upgrading to Windows Forms.

Steps to fix a migration issue

This section shows the recommended steps to fix an error related to EWIs. The steps are:

Locate the source of the problem

To find the source of the problem, you can add some breakpoints a few lines before the code where the exception or the different behavior manifests itself. You need to do this in both the original VB6 code and the upgraded code so that you can compare to find out what is causing the problem or why the problem is occurring.

Understand the code purpose in the original VB6 application

The next step is to understand, in the original VB6 application, the functionality of the section of the code causing the problem. You can perform the following activities to understand the original behavior:

  1. Create small examples of code that use the same features.

  2. Execute step by step (debug mode), as many times as you need, the section of code causing the problem.

Identify a solution in .NET

Once the functionality of the original VB6 application is understood, the next step is to replicate the same functionality in the upgraded .NET application. Some recommendations for this are:

  1. Create small examples in .NET to replicate the VB6 functionality.

  2. Review the related .NET documentation on the web to determine how to achieve the same functionality in .NET.

Implement the solution

If you already have a solution, you can implement it. Once you have modified the upgraded code and the found solution was implemented, you need to test your code to confirm that the behavior is the same as the original VB6 application. You can, also, review the rest of the upgraded code to determine if the same problem is present in other areas.

Mobilize.NET Customization (optional)

In some cases, you can consider Mobilize.NET Customization. Several factors must be taken into account at this point:

  1. Timing

    • Will the current timeframe of the project allows the Mobilize Team to implement the required customization? Is the impact of the error large enough to justify it to be reported in order to be included in future releases used in future projects?

  2. Complexity

    • Is there an opportunity to make the replacement in several places using another automated solution such as Regular Expressions?

  3. Rework required

    • Are the manual changes performed at this point in the project so many that executing a code merge will imply too much additional work?

Document the solution

Once the solution is implemented and the problem is resolved, it is important that the solution is properly documented and stored in a shared knowledge base. This helps in cases where other developers run into the same issue and are able to access information on how to solve it.

EWIs Lists

In the following lists, you can see the most common EWIs. It is important to know that there are many other EWIs not described in those lists.

Warnings

Below are a few of the most common warnings generated by the Visual Basic Upgrade Companion.

Code number

Description

206

1003

1044

1047

1049

1063

1068

2050

2065

2074

2077

2080

2081

2099

6002

6021

6022

7005

7006

7008

7009

8007

Issues

Below are a few of the most common issues generated by the Visual Basic Upgrade Companion.

Code number

Description

1002

1010

1014

1043

1046

2038

2064

2068

2070

7003

ToDos

Below are a few of the most common ToDos generated by the Visual Basic Upgrade Companion.

Code number

Description

1035

1050

1059

1065

1067

1069

2018

2045

7010

7016

Notes

Below are a few of the most common Notes generated by the Visual Basic Upgrade Companion.

Code number

Description

2041

6016

6017

7001

8001

8008

Ask your peers or a .

Mobilize.NET migration expert
Locate the source of the problem
Understand the code purpose in the original VB6 application
Identify a solution in .NET
Implement the solution
Mobilize.NET Customization
Document the solution
EWIs
Lset cannot assign one type to another
The preceding line couldn't be parsed
%1 statement is not supported
Class instancing was changed to public
%1 Parameter '%2' is not supported and was removed
Form property %1.ScaleMode is not supported
%1 %2 %3 %4 was not upgraded
%1 %2 was not upgraded
Constant %1 was not upgraded
The Hdc should be released once it is used for safety
The following line was commented
Structure %1 should be within the shared file due to its use in Declare statement for a Windows API
Inaccessible enum value %1 was changed to its numerical value %2
The following %1 (%2) seems to be dead code
Element %1 was removed
Element %1 is obsolete and should be removed
#If #EndIf block was not upgraded because the expression %1 did not evaluate to True or was not evaluated
Structure %1 may require marshalling attributes to be passed as an argument in this Declare statement
Code was upgraded to use %1 which may not have the same behavior
Error handling statement (%1) could not be converted
Member %2 is not defined in type %3
Error handling statement (%1) was converted to a pattern that might have a different behavior
Remove the next line of code to stop form from automatically showing
Only TrueType and OpenType fonts are supported in Windows Forms
The connection string must be verified to fullfill the .NET data provider connection string requirements
This property was auto-generated because it is used in WriteProperties but does not exist.
How to prevent the application from exiting immediately after starting
Untranslated statement in %1. Please check source code
ParamArray %1 was changed from ByRef to ByVal
Sub Main in a DLL won't get called
Application will terminate when Sub Main() finishes
Use of Null/IsNull() detected
Arrays in structure %1 may need to be initialized before they can be used
%1 of type %2 is being forced to %3
%1 Event %2.%3 was not upgraded
%1 %2 %3.%4 has a new behavior
%1 %2 %3.%4 was upgraded to %5.%6 which has a new behavior
Change the default 0 index in the Rows property with the correct one
%1 was upgraded to %2 and has a new behavior
%1 has a new behavior
Return value for Dir has a new behavior
UserControl Event %1 is not supported
Casting 'int' to Enum may cause different behavior
The CommonDialog CancelError property is not supported in .NET
Parameters (if any) must be set using the Arguments property of ProcessStartInfo
The named argument %1 was not resolved and corresponds to the following expression %2
The ProgId could not be found on computer where this application was migrated
Multiples invocations to ShowDialog in Forms with ActiveX Controls might throw runtime exceptions
Trying to marshal a non Blittable Type (%1). A special conversion might be required at this point. Moreover use 'External Marshalling attributes for Structs' feature enabled if required