Expert VB6 developers may sometimes pass the VB.Global object from the main VB6 project to a method exposed by an ActiveX DLL object. This advanced techniques was useful to allow the external DLL to access the current printer, the App object or the Forms collection of the main project.
Please notice that passing the VB.Global object to another DLL wasn’t a recommended VB6 practice, because the VB.Global class was private. (In fact, the receiving method has to declare a parameter of type Object or Variant, and access the object via late-binding.)
VB Migration Partner doesn’t support the migration of the VB.Global object. All occurrences of the VB.Global object are turned into references to CodeArchitects.VBMigrationEngine.Mirror_VB.GlobalObject, which cause a compilation error in the migrated project.
From the VB Migration Partner’s perspective, there is no VB.Global *instance* because the Forms, Screen, App, Printer, etc. global objects are defined in the VisualBasic_Support standard module (or in the VB6Project class if converting to C#). There are two ways to work around this limitation:
First, you can pass individual Forms, App, Printer, etc. properties instead of a single VB.Global object. This is the simplest technique, even though it requires that you modify either the original VB6 code or the migrated VB.NET code.
Second, insert the following class in a proper location of the current project:
Public Class VB6Globals
Public Shared ReadOnly Instance As New VB6Globals
Public ReadOnly Property Forms6() As VB6Forms
public class VB6Globals
public static VB6Globals Instance = new VB6Globals();
public VB6Forms Forms6
// similar code for other App, Printer, and other global objects
then modify all occurrences of the CodeArchitects.VBMigrationEngine.Mirror_VB.GlobalObject into VB6Globals.Instance. (You can automate these two tasks by means of pragmas: use a PostInclude or OutputMode pragmas to insert the new class in a proper location of your code, and use a PostProcess pragma to change all references to VB6Global.Instance.)
If you pass the VB6Globals.Instance reference to a different DLL, it is mandatory that you access its properties via late-binding, because the VB6Globals class defined in project A is different from the VB6Globals class defined in project B. For this reason, the receiving parameter in Project B can only be of type Object.