It’s no secret that a typical business application contains a lot of dead code that is never executed. This is especially true if the application has evolved over many years and has been authored by many developers. The percentage of useless code can vary, but is typical in the range 5% to 10%.

In a VB6 application this dead code consumes a little memory but doesn’t otherwise hurt the overall performance. However, things are quite different if you want to port that application to VB.NET – either by hand or automatically by means of a conversion tool.

In fact, if you have no way to spot where this dead code is, you might be wasting 5-10% of your time and money just to migrate code that will be never executed anyway. Considering how much migration initiatives may cost, this small percentage becomes a very high number in absolute terms.

VB Migration Partner has always included a very sophisticated code analysis engine that automatically spots portions of code that are unreachable – for example, the code that immediately follows an Exit Sub statement and that doesn’t begin with a label – as well as methods that aren’t referenced by code elsewhere in the same project or project group. VB Migration Partner distinguishes the two cases by means of different warning messages:

' UPGRADE_INFO (#0521): Unreachable code detected
' UPGRADE_INFO (#0501): The ‘XYZ’ member isn’t used anywhere in current application

The code analysis engine is smart enough to detect whether two methods call each other but not from the main application, or fields that are accessed only by methods that, in turn, are never invoked by other code. In this case the message is slightly different:

' UPGRADE_INFO (#0511): The ‘XYZ’ member is used only by members that
' haven’t found to be used in current application

Keep in mind that you can selectively disable warning messages by means of the DisableMessage pragma, as in:
    '## DisableMessage 521
or you can suppress all messages related to code analysis by means of the DisableMessages pragma:
    '## DisableMessages CodeAnalysis

Like all code analysis tools, VB Migration Partner may issue warnings related to members that appear to be unused only because the tool is analyzing one project at a time. For example, if you convert an N-tier application one component at the time, an analysis tool flags the majority of public members as “unused” even though they are used by client apps that haven’t been included in the code analysis. If the application isn’t too large, you can solve this issue by analyzing a project group that gathers all the individual projects, but this workaround isn’t practical for applications of dozens or hundreds different projects.

Another problem related to correctly spotting unused members is late-binding: if a given method or property is accessed by client code in late-bound mode, no code analysis tool is capable to detect that the member is actually used and shouldn’t be removed.

VB Migration Partner offers a “manual” solution to these problems in the form of two pragmas: the MarkAsReference pragma tells the code engine that a given member is actually referenced – for example, via late binding – and therefore the code analysis engine should omit warnings #0501 and #0511.

The MarkPublicAsReferenced pragma is useful when analyzing and migrating ActiveX DLL and OCX projects: when this pragma is used, all public properties and methods are marked as referenced. In turn, if these public members reference private variables or methods, these private members will be marked as referenced, too. The MarkPublicAsReferenced pragma can be scoped at the project or file level. For example, when migrating an ActiveX project, you typically need one single pragma:

    '## project:MarkPublicAsReferenced

All the features discussed so far have been available in all editions of VB Migration Partner since version 1.0. The forthcoming version 1.10 goes further, because it offers the ability to automatically remove unreachable code and unused members.

In version 1.10 you can remove unreachable code by means of the RemoveUnreachableCode pragma, which takes one of the following arguments: On (or omitted, remove the unreachable code), Off (don’t remove the unreachable code), Remarks (comment the unreachable code). For example, let’s consider this VB6 code:

Sub Test()
    ' GoSub DisplayMessage
    ' …
    ' more code here …
    ' …

    Exit Sub
DisplayMessage:
    MsgBox "Inside Test method"
    Return
End Sub


The code that begins with the DisplayMessage label was originally the target of the GoSub statement; it is clear that the developer later remarked out the Gosub keyword but forgot to delete the MsgBox and Return statements. This is how VB Migration Partner migrates this code:

Public Sub Test()
    ' GoSub DisplayMessage
    ' …
    ' more code here …
    ' …

    Exit Sub

    ' UPGRADE_INFO (#0521): Unreachable code detected

DoSomething:
    MsgBox6("Inside Test method")
    ' UPGRADE_INFO (#05A1): The VB6 code contains a Return but no
    ' GoSub has been found in current method.

    Err.Raise(3)
End Sub


Before deleting unreachable code, you might want to check that the program works correctly, by just commenting out the code, by adding the following pragma:

'## RemoveUnreachableCode Remarks
Public Sub Test()
    ...


This is what you get now:

Public Sub Test()
    ' GoSub DisplayMessage
    ' …
    ' more code here …
    ' …

    Exit Sub

    ' UPGRADE_INFO (#06F1): Unreachable code removed
    ' EXCLUDED: DoSomething:
    ' EXCLUDED: Beep()
    ' EXCLUDED: Err.Raise(3)

End Sub

Not that you are sure that the program works well, you can use the RemoveUnreachableCode pragma with no arguments:

'## RemoveUnreachableCode


which produces this code:

Public Sub Test()
    ' GoSub DisplayMessage
    ' …
    ' more code here …
    ' …

    Exit Sub

    ' UPGRADE_INFO (#06F1): Unreachable code removed

End Sub


Notice that the above code contains a new warning, which alerts you on the fact that some code has been removed. As usual, you can get rid of this new warning by means of a suitable DisableMessage pragma.

If you like the idea of automatically removing unreachable portions of code, you’ll surely appreciate the capability of doing the same with whole unused members, that is all the members that would be flagged with either the #0501 or #0511 warnings. In this case you need a RemoveUnusedMembers pragma, whose argument can be On (or omitted), Off, and Remarks – exactly like the RemoveUnreachableCode pragma seen above.
As before, you might want to remark out unused members first, to see how the code works

    '## RemoveUnusedMembers Remarks

and then delete them completely with
 
    '## RemoveUnusedMembers

When removing variables and methods, VB Migration Partner inserts a warning in the migrated code:

' UPGRADE_INFO (#0701): The 'XYZ' member has been removed because it
' isn't used anywhere in current application.

When running the tool to get the definitive VB.NET version of your code, it’s a good idea to get rid of this message with

    '## DisableMessage 0701


One final note: The ability to selectively indicate which members are to be considered as referenced makes VB Migration Partner stand out among other analysis/migration tool that don’t offer the ability to remove dead code or that allow you to enable this feature only at the project-level.

In fact, when migrating large and complex N-tier application, you can rarely remove all unreferenced members, because they might be referenced in client apps that aren’t part of the same project group. In practice, if a tool doesn’t give you the option to selectively decide which members should be removed, this feature is rarely usable when migrating large applications.