MethodViz - See what your methods are doing ...

For those, who don't like Python or IronPython, here is a pure C# version of Method Visualizer.  The following screenshot shows it in action.

Here is a brief description about MethodViz:

MethodViz is a simple method hierarchy visualizer. It lets you see the method tree from a particular method.

Let's see this with an example.

This is a simple diagram for a case where PublicMethod( ) is calling Help( ) which is then calling HelpMeToo( ). You can see that the root methods and the other methods are from different classes.

For more detailed description, see the following blog posts:

http://weblogs.asp.net/nleghari/pages/ironpythoncecil.aspx
http://weblogs.asp.net/nleghari/archive/2007/04/02/fun-with-ironpython-glee.aspx
http://weblogs.asp.net/nleghari/archive/2007/04/02/fun-with-ironpython-and-cecil-part-ii.aspx
http://weblogs.asp.net/nleghari/archive/2007/04/03/method-tree-visualizer-fun-with-ironpython-cecil-and-netron-graph-part-iii.aspx

Currently MethodViz supports the following type of method calls.

Normal Calls:

Described above.

Interface Calls:

Similarly, it will detect the correct instance even if you are calling from an interface or an abstract. I'll leave the "How" section to another blog post.

public void CheckDraw()
{
            IShape d = new RectangleShape();
            IShape d2 = new CircleShape();
            d2.Draw();
            d.Draw();
}

Here IShape is an interface which is used to called the concrete implementations.  The following is the generated graph for the above method.

Although not shown above, but the Draw( ) methods for each concrete implementation are calling another method as clear by the diagram.

Abstract Classes:

Similar to the interfaces, the abstract classes are also mapped clearly.

public void CheckAbstractImplementation( )
{
            AbsClass ab = new AbsClassImpl();
            ab.MethodImpl();
            ab.MethodNotImpl();
}

In the above method, AbsClass is an abstract class where AbsClassImpl is the concrete implementation. Note that MethodImpl( ) is implemented by AbsClass whereas MethodNotImpl( ) is implemented by AbsClassImpl. Let's see how the diagram looks like.

Note the Class names highlighted by the red marker.

Cross Assembly Calls:

Another thing that it does it to automatically resolve assembly references ( * ) and connect those methods.

public void CrossAssemblyCall( )
{
            CecilSecondCase.CSCTypeA newObject = new CecilSecondCase.CSCTypeA();
            newObject.HelloWorld();
}

The above method creates an instance of CSCTypeA class which is in CecilSecondCase.dll assembly. (Shown below)

public class CSCTypeA
{       
        public void HelloWorld( )
        {
            this.SayHello("CecilSecondCase::HelloWorld");
        }

        private void SayHello(string msg)
        {
            CTCTypeA thirdCase = new CTCTypeA();
            thirdCase.HelloWorld();
        }
}

This class in turn create an instance of CTCTypeA which resides in the CecilThirdCase.dll assembly (Not showing here as it is similar to CSCTypeA). Hence the flow looks like this:

Main Assembly -> CecilSecondCase -> CecilThirdCase

The final diagram for the above method tree looks like this:

(Marker is only used to clear the point)

( * ) There are some restrictions as it only tries in the current directory for the assembly with the dll extension only.

Issues:

The current release is like an alpha version of MethodViz. You may get incomplete graphs for some methods. In that case, you can check the log file generated in the exe directory.

The only known issue is no support for Generic method calls. So if your method contains a call to a generic method then this will definitely fail. You can just Continue there instead of Quit to check the other methods. It fails due to the IL representation of Generic method call.

newobj instance void CecilCase.Stack`1<int32>::.ctor()

This is a call to create a new object of a generic Stack. It blows up when the name is converted to XML and passed to XMLVisualizer to render because of invalid characters in XML. 

update: FIX the above issue with generics. The same download link will get the updated source and binaries. 

Download And Usage:

Download Here
The download contains the source and the binaries.

To try this, just extract is anywhere you like. You can start by running the "FrontEnd.exe" file in the bin\Debug folder. Once you see the window, you can open an assembly by click File -> Open Assembly. For playing with this, you can select "CecilCase.dll" which you'll find in the same directory and try out different methods.

Feedback:

I would really appreciate if you try this and see what works and what not. And also give your suggestions to include anything you like to see.

4 Comments

  • Nice control...

    It seems that your examples about resolving virtual methods (i.e. interfaces and abstract classes) are too trivial.

    Instanciating a concrete class, assigning it to a local and calling that interface rarely happens in the same metod body. It usually gets split between differnt methods: one store an interface instance, one makes the call. In that case, things become non trivial: any type that implements that interface could be passed, and there's no guarantee to resolve precisely the concrete type.

  • Great!

    in AssemblyData.cs, the method "AddType" of FrontEnd.CecilAssemblyData class may throw a exception that is "a key has exited in a dictionary" when the program is loading an assembly dll(.net 1.1) file.

    internal void AddType(TypeDefinition tDef)
    {
    if (Rules.IsValidType(tDef.FullName))
    {
    this.typeDic.Add(tDef.FullName, tDef);
    }
    }

  • Promising tool.

    The main problem for me right now is zooming. I don't know if the graph library supports it, but zooming in/out with the mouse will be a great bonus.

    Also, integration with Reflector to view the code for the methods will be great.

    Greetings from Spain

  • Yes yes, please make this a Reflector plug-in

Comments have been disabled for this content.