VS2010 Dependency Graph gotchas

We need to refactor a solution with 200+ projects in Visual Studio 2010. The solution must be split into a runtime and a design solution. As we have the Ultimate edition, the Architecture features will be used. With the Dependency Graphy we planned to view which projects could be simply moved and which projects needed some refactoring. But we came across some gotchas.

To simplify my post and not disclose any details I made a demo project with the problems. The classes are below and can be downloaded at the end of this post. Of course I coded one class per file and one namespace per assembly, but to save space the code below is combined. Also some logic is removed to improve readability

Generics

The Util class DoMyAction is used to perform an action on a IDisposable object. The Using method is generic as it accepts the Type to perform the action on by <T>. In the Businesslogic class Rules this is used to do some checking of the Person object. (that implements IDisposable)

namespace Util 
{
    public static class DoMyAction 
    {
        public static void Using<T>(T client, Action<T> action) where T : IDisposable 
        {
            action(client);
            client.Dispose();
        }
    }
}

namespace BusinessLogic 
{
    public class Rules 
    {
        public void PerformCheck(Person item) 
        {
            // use of class from Util assembly
            Util.DoMyAction.Using<Person>(item, NameNotEmpty);
        }

        public void NameNotEmpty(Person p) 
        {
            // some logic
        }
    }
}

When Visual Studio generates the dependency graph by assembly (picture below) the references between the assemblies are not shown. Externals and Generics are added automatically.

The Generics group contains the dynamic generated DoMyAction method for the Person type. Opening the Generics group shows the DoMyAction class that is the link between the Businesslogic and Util assembly. In the picture below the arrows have been traced 🙂

So the link is there but you have to search for it.

Const

As you could see in the Dependency Graphs above we use a Constant assembly to store those hardcoded strings and provide some sharing. The compiler actually replaces the constant in the code with the value of that constant (MSDN) as you can check with reflector. The Dependency Graph uses the IL code and therefore cannot know the constant is defined in another assembly.

General hickup

The generation failed for the original solution. We think this is because it contains silverlight assemblies with linked files and Visual Studio cannot unique identify these duplicate files. To be continued …

Download Demo project

Static (printouts) graphs will never contain all the information and be readable at the same time. The dependency graph is a great tool to interact with your codebase. I think that is the only way to document your solution.

[edit August 27, 2012]
Figured out a workaround for the crash from the General hickup.

Start the Architecture Explorer from the Architecture > Windows menu (CTRL + W, N)

Choose new Graph in the tool window

Drag-n-drop the assemblies you want to investigate onto the canvas

tip: CTRL + F will work for finding your assembly

tip: Use the Neighborhood Browse Mode to find references down the line

[/edit]