views:

366

answers:

5

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.

+3  A: 

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.

Jon Skeet
yes, I would like to break the assemblies up, but Visual Studio performs really bad when you start to have more than 40 or so projects in your solution (especially when your dev machine is 5 years old)
Mark Heath
You should be able to make the case for an update to your dev machine then... and think about whether you need all those projects in the same solution. It sounds like you've got 1 project here which should be two - do you have others which should be combined?
Jon Skeet
well its one big WinForms executable that hosts 8 or 9 sub-"applications", so once you have factored out the shared code into reusable components and added some unit test assemblies, the number of projects gets quite high.
Mark Heath
I suspect I'd refactor that into multiple solutions - one for each subapplication, the "shell", and a "common code" solution. I know it's a pain to do references to files rather than projects, but it does keep things nippier.
Jon Skeet
yes, this is exactly what I would like us to do.
Mark Heath
A: 

Reflector does this.

Right click namespace, click Analyze, viola! :)

leppie
a useful tip but it seems to only show what assemblies my namespace depends on, not what namespaces
Mark Heath
+2  A: 

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 the lead developer of 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: Dependencies Matrix, Graph and also you can write some CQL queries and rules to detect cycle between namespaces, or enforce some particular dependencies.

Btw, I wrote an article about why prefering few big assemblies with many namespaces over having plenty of small assemblies: Control components dependencies to gain clear architecture

Patrick Smacchia - NDepend dev
We downloaded NDepend a while ago to evaluate it. There is a lot to learn and I am still getting to grips with the meaning of the matrix. I would be interested to see if I could write CQL to query specific dependencies between namespaces.
Mark Heath
Mark, for example :// Make sure no dependencies cycles between namespacesWARN IF Count > 0 IN SELECT ASSEMBLIES WHERE ContainsNamespaceDependencyCycle // Avoid App.UI.* to use App.DBWARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "App.DB" AND NameLike "App.UI"
Patrick Smacchia - NDepend dev
Mark, I wanted to let you know that we released recently some sort of Context-Sensitive Help in NDepend that helps a lot to learn the tool features and especially the Dependency Matrix
Patrick Smacchia - NDepend dev
+2  A: 

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

Tom Carter
This plugin is great, I've just been using it to analyse and refactor a largish project and it provides exactly the information you need. Thanks!
Dave
A: 

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

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

Esther Fan - MSFT