After translating your migration projects, you can generate Semantic Model Reports. Semantic Reports are similar to CodeScan reports but they are produced by analyzing the compiled code rather than by scanning the source code directly. They facilitate a much more detailed look into your system.
Semantic References: a detailed look at referenced symbols. Answers the question: what symbols are referenced and how are they used? Includes only those symbols that are actually used.
SrcName ' Migration Unit Name RunDate ' Semantic Model Creation Date RecType ' Report Type MemName ' Member Name MemClas ' Member Parent MemLibr ' Member Library MemType ' Member Type Pos_Cnt ' Referring Location LocText ' Referring Source LocMemb ' Referring Member LocFile ' Referring File LocName ' Referring Type LocType ' Referring File Type
Semantic Definitions: a detailed look at defined symbols. Answers the question: what symbols are defined and how are they used? Includes all symbols defined in code and in referenced libraries.
SrcName ' Migration Unit Name RunDate ' Semantic Model Creation Date RecType ' Report Type MemName ' Member Name MemClas ' Member Parent MemLibr ' Member Library MemType ' Member Type Pos_Cnt ' Definition Count (0 if not explicitly used; this can be used to help you identify dead code) LocText ' Definition Text LocFile ' Defining File LocName ' Defining Type LocType ' Defining File Type
Identifying Dead Code
The Analytics/Semantics Definitions reports can help with identifying dead code. The Pos_Cnt field is the number of references detected by the tool. So a zero means not used.
Another, more tedious, way to to identify unused symbols is to look for the symbol in the Analytics/Semantics References report. If a symbol is NOT FOUND as referenced in the References report, then it may be dead and the corresponding record for the symbol in the Definitions report should have Pos_Count=zero.
You need to be careful interpreting these results. Some things to be aware of: event-handlers may be needed but are rarely explicitly called, and late calls (CallByName and dynamic) are not detected either. So it is possible to detect 0 calls, but still have calls at runtime. It is a critical to audit the code for late calls and refine the upgrade solution to enhance type inference hints if you are finding unexpected late calls. Also, the dead code analysis gets more difficult when dealing with members in COM DLLs. One must inspect all client code that might use the DLL to see if the member is called through COM. This is only possible if you have source code for all clients. If you only have Standalone EXEs, this complexity is not a concern.
A dump of the symbol table. Includes all symbols defined in code or in referenced libraries.
SrcName ' Migration Unit Name RunDate ' Semantic Model Creation Date Lev ' Symbol's Level in the Model Hierachry Address ' Symbol's Address Parent ' Symbol's Parent address Type ' Symbol's Type FullIdentifier ' Symbol's Fully-Qualified Identifier
A detailed report showing the internal semantic model contents in terms of symbol tables and low-level semantic operations. These reports can be useful for implementing advanced refactoring rules that manipulate operation streams. There are two types of Semantic Audits: