Detecting dependencies between namespaces in .NET

问题:

Are there any utilities that can examine a set of managed assemblies and tell you whether any of the types in one namespace depend on any in another? For example, say I have a MyApp.BusinessRules namespace and don't want it to access directly anything in MyApp.GUI, but both namespaces are in the same assembly. My goal is to be able to write a custom MSBuild task that verifies that various coupling rules have not been broken.

So far the only tool I have come across that looks like it might do this is NDepend, but I am wondering if there is a simpler solution.

回答1:

So far the only tool I have come across that looks like it might do this is NDepend, but I am wondering if there is a simpler solution.

I am one of the developer of the tool NDepend. Please could you let us know what do you find complicated in NDepend and how you imagine a simpler solution for you?

NDepend comes with 3 different ways to do what you want: Dependency Matrix, Dependency Graph and also you can write some Code Rule over LINQ Query (CQLinq) and rules to detect cycle between namespaces, or enforce some particular dependencies.

For example, say I have a MyApp.BusinessRules namespace and don't want it to access directly anything in MyApp.GUI, but both namespaces are in the same assembly.

For that, the following CQLinq rule can be written, could it be any simpler than that?:

warnif count > 0
let businessRules = Application.Namespaces.WithNameLike("^MyApp.BusinessRules")
let gui = Application.Namespaces.WithNameLike("^MyApp.GUI")

from n in businessRules.UsingAny(gui)
let guidNamespacesUsed = n.NamespacesUsed.Intersect(gui)
select new { n, guidNamespacesUsed }

回答2:

I suspect NDepend is going to be the simplest way to go, to be honest.

However, if you really don't want bits of one assembly from referring to each other, you should almost certainly split the assembly up into more logical units.

回答3:

You can analyze namespace dependencies with the DSM plugin for .NET Reflector ( I'm its developer)

Once the assemblies are analyzed you can save the project to a file. This file is just XML with a simple structure so you can pass it to a script for custom analysis

[Update]: This plugin is now available in form of a Visual Studio Add-In

回答4:

You can try the RC release of Visual Studio 2010 Ultimate to generate dependency graphs for .NET code. You can generate a graph of all your assemblies, namespaces, classes, or some combination of these, or you can use Architecture Explorer to select specific artifacts and the relationships that you want to visualize.

You can also create layer diagrams from dependency graphs or from the existing artifacts, draw the permitted dependencies, and then include layer validation as part of the MSBuild process to make sure invalid dependencies aren't introduced:

How to: Generate Graph Documents from Code: http://msdn.microsoft.com/en-us/library/dd409453%28VS.100%29.aspx#SeeSpecificSource

You can use Visual Studio Ultimate to explore the relationships and organization in existing code by generating directed graph documents. These graphs represent code elements and their relationships as a set of nodes that are connected by links, or edges. You can use these graphs to help you visualize, explore, and analyze code.

How to: Find Code Using Architecture Explorer: http://msdn.microsoft.com/en-us/library/dd409431%28VS.100%29.aspx

You can select vertical sections or "slices" of code that you want to visualize by using Architecture Explorer. You can explore source code in a Visual Studio solution or compiled managed code in .dll files or .exe files. You can use Architecture Explorer to browse other domains by installing additional providers. When you find the code that you want to visualize, you can generate graphs to explore the relationships in that code.

How to: Create Layer Diagrams from Artifacts: http://msdn.microsoft.com/en-us/library/dd465141%28VS.100%29.aspx

...use layer diagrams to visualize the high-level architecture of your system and to verify that the code complies with this design. To perform this task, organize and associate the artifacts from a Visual Studio solution into logical, abstract groups, or layers. These layers describe major tasks that these artifacts perform or the major components of your system. Arrows between the layers represent the interdependencies that exist or should exist between these artifacts. To enforce architectural constraints on the code, describe the intended dependencies on the diagram and then validate the code against the diagram. By using layer diagrams in this manner, you can help make the code easier to understand, reuse, and maintain.

Layer Diagram http://i.msdn.microsoft.com/Dd465141.UML_LayerRefReading(en-us,VS.100).png

How to: Validate Code Against Layer Diagrams: http://msdn.microsoft.com/en-us/library/dd409395%28VS.100%29.aspx

Validating code against a layer diagram helps you enforce architectural constraints on the code as it evolves. When you perform this task, dependencies in the code are compared with dependencies on the diagram.

RC download: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=457bab91-5eb2-4b36-b0f4-d6f34683c62a.

Visual Studio 2010 Architectural Discovery & Modeling Tools forum: http://social.msdn.microsoft.com/Forums/en-US/vsarch/threads

回答5:

Reflector does this.

Right click namespace, click Analyze, viola! :)