As early as Visual Studio 2002, Visual Studio has supported the ability to see the dependencies between projects in a solution. However, the experience is somewhat clunky in that you can only see the dependencies one project at a time.
In the example below, you can see the project dependencies for the Patient Monitoring project. However, as I mentioned above, the major drawback to this approach is that you can only see the dependencies one project at a time and don’t get to see a "global view" of your solution. There is also another scenario that today’s solution doesn’t solve. The problem is that the only way to find out why a dependency exists is to look at the code or use some other tool. In the screenshot below, the Project Dependencies dialog doesn’t tell you why the Patient Monitoring project is dependent on the Chart project.
Architecture Explorer in Team System 2010 not only allows you to see the project dependencies for the entire solution but it also allows you to see the reason why each dependency exists. Each arrow in the screenshot below represents a dependency. Furthermore, the thickness of an arrow indicates the size of the dependency. Notice that there are no arrows going in or out of the ChartVisuals project. Using the Architecture Explorer, I discovered that this project is not being used anywhere!
To investigate a dependency further, you can expand the chevron (double arrows) on each node. This will not only display the classes within a project but it will also draw arrows from the classes that have dependencies on other projects. You can even dig one level deeper to see the methods in those classes that are calling into the dependencies. This is shown via the blue arrows below.
In a future blog post, I’ll walk through how to use the Architecture Explorer to analyze circular references and class coupling.