Avoid partitioning the code base through many small library Assemblies
Matches assemblies with 3 or fewer types. Each assembly is a DLL and a project to maintain; too many is a symptom of treating physical projects as logical components. Prefer fewer, bigger projects with namespaces as logical components: faster compilation and startup, clearer Solution Explorer, easier deployment, fewer assemblies for library clients.
How to fix
Use the physical concept of assemblies for physical needs only. Our white book Partitioning code base through .NET assemblies and Visual Studio projects details valid and invalid reasons: https://www.ndepend.com/Res/NDependWhiteBook_Assembly.pdf
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>Avoid partitioning the code base through many small library Assemblies</Name>
// <Id>ND1402:AvoidPartitioningTheCodeBaseThroughManySmallLibraryAssemblies</Id>
warnif count > 10
from a in JustMyCode.Assemblies where
// Don't match ASP.NET Core generated assemblies
// whose name is suffixed with '.Views'
!a.Name.EndsWith(".views", StringComparison.OrdinalIgnoreCase) &&
( a.ChildTypes.Count() <= 3) &&
// Don't match executable assemblies that can be small
!a.ChildMethods.Any(t => t.IsEntryPoint) &&
!a.ChildTypes.WithNameIn("Startup","Program").Any() &&
// Don't match DI assembly
!a.IsUsing(@"Microsoft.Extensions.DependencyInjection".MatchNamespace().AllowNoMatch())
select new {
a,
a.ChildTypes,
a.NbLinesOfCode,
a.NbILInstructions,
Debt = 40.ToMinutes().ToDebt(),
Severity = Severity.Medium
}
//<Expl>
// The *library {0}* contains only the *{1}*.
// Avoid creating numerous small projects as they usually complicate
// code maintenance and usage.
//</Expl>
//<Desc>
// Matches assemblies with 3 or fewer types. Each assembly is a DLL and a
// project to maintain; too many is a symptom of treating **physical**
// projects as **logical** components. Prefer fewer, bigger projects with
// namespaces as logical components: faster compilation and startup, clearer
// Solution Explorer, easier deployment, fewer assemblies for library clients.
//</Desc>
//<HowToFix>
// Use the *physical* concept of assemblies for physical needs only. Our
// white book **Partitioning code base through .NET assemblies and Visual
// Studio projects** details valid and invalid reasons:
// https://www.ndepend.com/Res/NDependWhiteBook_Assembly.pdf
//</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