Action Look at the project references for a given project and then look at the next one. Dialogue Suppose your team has had ...

Action
Look at the project references for a given project and then look at the next one.

Dialogue
Suppose your team has had to run multiple builds to get a successful build.

You think a circular dependency exists somewhere, but where is it?

Did you ever want to know why your projects have particular dependencies? 

Suppose you wanted to remove an assembly, or update to a new technology? 

The Visual Studio dependency graphs can help you with this. 



Action
On the Architecture menu, choose Generate Dependency Graph, and then For Solution.

Dialogue
You can get a high-level picture of your solution by generating a dependency graph for the solution.

This can be very useful because you might see things that surprise you.

For example, we see immediately that the Unit Tests don't actually test anything in the solution.  Actually, they don't test anything at all.



Action
On the Legend, choose Add, and a circular dependency analyzer.

Dialogue
This solution is pretty big, so we don't immediately see any unexpected dependencies. 

However, you can add a circular dependency analyzer to help you find these dependencies. 



Action
As a result, 3 assemblies are highlighted.

Dialogue
And indeed, we see these 3 assemblies reference each other. 

This saved us a lot of time. Now we need to fix this! 



Action
Examine the links between the 3 assemblies.

Dialogue
Notice here that the dependency link between this assembly and this assembly is much thinner than the links between the others. 

When we move the mouse on top of the link, the tooltip tells us only 2 calls produce this dependency. This makes it look like the dependency was added recently.



Action
Click the suspicious (thinner) link, and request the contributing links.

Dialogue
By understanding what contributes to a dependency, we can immediately see which methods call methods in other assemblies. And it looks like only one method is called here. That's good. 

By adding the contributing links to the big picture, we also get all the links from this method to other parts of the code. 

It seems we could move this method into the other assembly without much problem. Let's see if we're right.



Action
Drag and drop the method to the calling assembly. See that this does not fully solve the problem. 

Dialogue
We see that there's another link to a static field. We can move that too.



Action
Drag and drop the field, which solves the problem.

Dialogue
So, we were able to test our theory and find the right fix.



Action
Press F12, or use the goto code shortcut menu command. 

Split the screen into the graph and the code, and then use the graph to help navigate to the code.

Dialogue
We can now use the diagram as a map to find the code and actually make the fix.



Action
Add a comment explaining the purpose of the new design, and add this diagram to the project to include it in a sheveset, or Export as XPS to print out.

Dialogue
And then, we can share the new design with the team, for instance part of a code review.