Example of custom rule to check for dependency
A sample rule showing how to check if a dependency exists from a code element A to B (each being an Assembly, Namespace, Type, Method or Field, not necessarily of the same kind).
Generate such a rule by right-clicking the Dependency Matrix cell (B in row, A in column) or the Dependency Graph arrow from A to B, then clicking Generate a code rule that warns if this dependency exists. Adapt the generated rule to your needs.
Generate such a rule by right-clicking the Dependency Matrix cell (B in row, A in column) or the Dependency Graph arrow from A to B, then clicking Generate a code rule that warns if this dependency exists. Adapt the generated rule to your needs.
How to fix
This is a sample rule, there is nothing to fix as is.
CQLinq source
This rule is written in CQLinq, C# LINQ over the NDepend code model. It ships with every new NDepend project: you can read it, adapt it, or use it as a starting point for your own custom rules.
// <Name>Example of custom rule to check for dependency</Name>
// <Id>ND9900:ExplicitId9900</Id>
warnif count > 0 from a in Application.Assemblies
where
a.IsUsing("Foo1.Foo2".AllowNoMatch().MatchNamespace()) &&
(a.Name == @"Foo3")
select new {
a,
a.NbLinesOfCode,
// Debt and Severity / Annual Interest can be modified to estimate well the
// effort to fix the issue and the annual cost to leave the issue unfixed.
Debt = 30.ToMinutes().ToDebt(),
Severity = Severity.High
}
//<Expl>
// The *{0}* shouldn't use directly the namespace *Foo3.Foo4*
// because (TODO insert your reason).
//</Expl>
//<Desc>
// A **sample rule** showing how to check if a dependency exists from a code
// element **A** to **B** (each being an *Assembly*, *Namespace*, *Type*,
// *Method* or *Field*, not necessarily of the same kind).
//
// Generate such a rule by right-clicking the *Dependency Matrix* cell (**B**
// in row, **A** in column) or the *Dependency Graph* arrow from **A** to
// **B**, then clicking
// **Generate a code rule that warns if this dependency exists**.
// Adapt the generated rule to your needs.
//</Desc>
//<HowToFix>
// This is a *sample rule*, there is nothing to fix *as is*.
//</HowToFix>
Open in the interactive Rules Explorer · All default rules
Architecture: all 13 items
- Avoid namespaces mutually dependent ND1400
- Avoid namespaces dependency cycles ND1401
- Avoid partitioning the code base through many small library Assemblies ND1402
- Enforcing Clean Architecture ND1412
- UI layer shouldn't use directly DB types ND1403
- UI layer shouldn't use directly DAL layer ND1404
- Assemblies with poor cohesion (RelationalCohesion) ND1405
- Namespaces with poor cohesion (RelationalCohesion) ND1406
- Assemblies that don't satisfy the Abstractness/Instability principle ND1407
- Avoid excessive class coupling ND1410
- Higher cohesion - lower coupling ND1408
- Avoid mutually-dependent types ND1409
- Example of custom rule to check for dependency ND9900