In VB6 it is legal to define a method that has the same name as an event exposed by the current form, class, or UserControl. For example, a form can expose a method named MouseMove even though the form’s base class exposes an event with same name:

 
        ' this is the MouseMove method
        Public Sub MouseMove(ByVal x As Long, ByVal y As Long)
            ' …
        End Sub

        ' this is the handler for the MouseMove event
        Sub Form_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single)
            ' ...
        End Sub

Unfortunately, such a method definition is illegal under .NET or C#. VB Migration Partner solves the problem by marking the method with the Shadows or new keyword, as in this code:

 
        'VB.NET
        ' this is the MouseMove method
        Public Shadows Sub MouseMove(ByVal x As Integer, ByVal y As Integer)
            ' ...
        End Sub

	' this is the handler for the MouseMove event
        Sub Form_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single) _
              Handles MyBase.MouseMove
            ' ...
        End Sub

 
        // C#
        // this is the MouseMove method
        public new void MouseMove(int x, int y)
	{
	    // …
	}

	// this is the handler for the MouseMove event
	private void Form_MouseMove(int Button, int Shift, float X, float Y) _
	{
	    // …
	}

Thanks to this mechanism, references to the method work correctly in converted VB.NET programs. If the target method is defined in a different BAS module, VB Migration Partner solves the ambiguity by prefixing the method’s name with the module’s name:

 
        MouseMethods.MouseMove(10, 20)

(When converting to C#, method names are always prefixed by a class name if they are invoked from another class.)