This project has moved. For the latest updates, please go here.
This project has been moved to GitHub.
For the latest documentation please follow this link:


This example is taken from the NsDepCop tool itself. A package diagram depicts the namespaces and their dependencies and two dependency config files show how those dependencies are represented as rules.

Consider the following package diagram.
  • NsDepCop.MsBuildTask and NsDepCop.Core are two assemblies (and C# projects) and they both have a dependency config file (see below).
  • The colored numbers help to identify which dependency is described by which rule element.
  • The star symbol on some arrow ends means that the whole package subtree is included in the rule.
  • The VisibleMembers elements in one of the config files define the types that are exposed to other namespaces.

nsdepcop.config for NsDepCop.MsBuildTask

nsdepcop.config for NsDepCop.Core

You can read the picture (and the corresponding rule config files) like this:
  • The NsDepCop.Core package is devided into Interface, Factory and Implementation packages.
    • Interface is not dependent on anything.
    • Implementation (and its sub-packages) can depend on Interface in order to realize it.
    • Implementation.NRefactory depends on the NRefactory libraries (ICSharpCode.NRefactory namespace and its children).
    • Implementation.Roslyn depends on the Roslyn libraries (Microsoft.CodeAnalysis namespace and its children).
    • Factory depends on both Interface and Implementation.
    • But Implementation exposes only some types: DependencyAnalyzer from the NRefactory and Roslyn packages and TypeDependencyValidator from the Common package.
  • NsDepCop.MsBuildTask implements the MsBuild-hosting of NsDepCop.
    • It uses the NsDepCop.Core package as a client, so it depends on Interface and Factory packages.
    • It can also depend on the MsBuild library (Microsoft.Build namespace and its children).

Last edited Mar 26 at 1:15 PM by vizu, version 13


No comments yet.