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


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 

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.


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.

  1. Start the Architecture Explorer from the Architecture > Windows menu (CTRL + W, N)
  2. Choose new Graph in the tool window Mouse pointer on "new graph document" button
  3. Drag-n-drop the assemblies you want to investigate onto the canvas
  4. tip: CTRL + F will work for finding your assembly
  5. tip: Use the Neighborhood Browse Mode to find references down the line


About erictummers

Working in a DevOps team is the best thing that happened to me. I like challenges and sharing the solutions with others. On my blog I’ll mostly post about my work, but expect an occasional home project, productivity tip and tooling review.
This entry was posted in Development and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.