.NET assembly analysis

What is .NET assembly analysis?

Project Analyzer can analyze binary .NET assembly files used in a Visual Basic .NET project. It requires that the used .NET assemblies are available on the system.

.NET assembly analysis reads the types, methods, fields and other related information stored in a .NET assembly. This describes the public interface that is available for others to call. .NET analysis is not the same as a disassembler. It does not reveal the source code of a binary file, nor does it show the internal logic of a binary. Thus, when you have the source code for a .NET assembly available, it's better to analyze the source rather than the binary.

When you include a .NET assembly in your analysis, its contents appear in Project Analyzer as regular classes, procedures, events, enums etc.

What results do I get?

.NET assembly analysis reveals the dependencies between your code and a .NET assembly file. For any procedure you can see where it's being used by viewing the call trees. In a file dependency tree, you can see which source code files actually call the assembly. Or, for a given source code file or procedure, you can see which assemblies it requires.

Finding dead code, or other programming problems, is not part of .NET assembly analysis. Dead code and other problem information is useless for binary files for which you have no source code. If you have the source, you can analyze it instead of the binary. Just do a multi-project analysis with the user project(s) and the library project(s). This way you can find out which procedures are dead and what other problems there may be in the code.

Requirements

Analysis works with .NET assemblies for all framework versions from 1 to 4.5. However, you need to have .NET Framework 4 or 4.5 installed. The framework is automatically installed by Visual Studio 2010, 2012, 2013, Windows 8, 8.1 and 10 and Windows Server 2012. If you don't have any of these installed, you may need to download the framework from Microsoft. (read more)

Limitation: Support for 64-bit assemblies is not guaranteed.

.NET assembly analysis is primarily designed to work with .NET Framework libraries that are installed in GAC. It supports the regular .NET Framework libraries. Analysis of other frameworks, such as Silverlight, may not work perfectly.

Note: The .NET Framework assemblies are large. Including the in the analysis can slow Project Analyzer down, especially when the source code is large as well. To speed things up you can drop .NET assemblies from the analysis when you don't need them.

.NET troubleshooting

Problem: .NET assemblies don't show up

Make sure you have .NET Framework 4, 4.5 or 4.5.1 installed.
Make sure proasm.dll is in your Project Analyzer directory. Double-click proasm.reg to install it.

Problem: .NET assembly doesn't appear in library file list

Make sure the file is referred to in your project(s).
Verify that file you want to analyze is actually a .NET assembly. Not all .dll or .exe files are .NET assemblies.
Is the file installed in GAC? If not, put it there.
Is this a .NET Framework assembly? Analysis may not be able to detect non-framework assemblies.

Problem: .NET assembly doesn't get analyzed

Make sure that you have selected the file for analysis when you start the analysis.

Problem: Incorrect mscorlib version is analyzed

This is a known limitation. The analyzed version of mscorlib.dll actually belongs to .NET Framework v4.

Problem: No project uses an assembly

To analyze an assembly, you need a project that actually references it. You cannot analyze a single assembly without a VB project.

Problem: Calls from a VB classic project to a VB.NET assembly are undetected

This analysis is not supported.