NetArchTest.Rules 1.3.2

dotnet add package NetArchTest.Rules --version 1.3.2
NuGet\Install-Package NetArchTest.Rules -Version 1.3.2
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="NetArchTest.Rules" Version="1.3.2" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add NetArchTest.Rules --version 1.3.2
#r "nuget: NetArchTest.Rules, 1.3.2"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install NetArchTest.Rules as a Cake Addin
#addin nuget:?package=NetArchTest.Rules&version=1.3.2

// Install NetArchTest.Rules as a Cake Tool
#tool nuget:?package=NetArchTest.Rules&version=1.3.2


A fluent API for .Net Standard that can enforce architectural rules in unit tests.


This project allows you create tests that enforce conventions for class design, naming and dependency in .Net code bases. These can be used with any unit test framework and incorporated into a build pipeline. It uses a fluid API that allows you to string together readable rules that can be used in test assertions.

There are plenty of static analysis tools that can evaluate application structure, but they are aimed more at enforcing generic best practice rather than application-specific conventions. The better tools in this space can be press-ganged into creating custom rules for a specific architecture, but the intention here is to incorporate rules into a test suite and create a self-testing architecture.


// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()

// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()

// All the service classes should be sealed
result = Types.InCurrentDomain()

Getting started

It is a .Net Standard 2.0 library that is compatible with .Net Framework 4.6.1 or better and .Net Core 2.0 or better.

Writing rules

The fluent API should direct you in building up a rule based on a combination of predicates, conditions and conjunctions.

The starting point for any rule is the static Types class, where you load a set of types from a path, assembly or namespace.

var types = Types.InAssembly(typeof(MyClass).Assembly);

Once you have selected the types you can filter them using one or more predicates. These can be chained together using And() or Or() conjunctions:


Once the set of classes have been filtered you can apply a set of conditions using the Should() or ShouldNot() methods, e.g.


Finally, you obtain a result from the rule by using an executor, i.e. use GetTypes() to return the types that match the rule or GetResult() to determine whether the rule has been met. Note that the result will also return a list of types that failed to meet the conditions.

var isValid = types.That().ResideInNamespace(“MyProject.Data”).Should().BeSealed().GetResult().IsSuccessful;

Custom rules

You can extend the library by writing custom rules that implement the ICustomRule interface. These can be applied as both predicates and conditions using a MeetsCustomRule() method, e.g.

var myRule = new CustomRule();

// Write your own custom rules that can be used as both predicates and conditions
result = Types.InCurrentDomain()

Grouping rules into Policies

Rules can be grouped into policies using the fluent interface exposed by the Policy class, e.g.

var architecturePolicy = Policy.Define("Example Policy", "This is an example policy")
                .Add(t =>
                   "Enforcing layered architecture", "Controllers should not directly reference repositories"
                .Add(t =>
                    "Generic implementation rules", "Interface names should start with an 'I'"

The rules are loaded lazily and executed when the Evaluate() method is called. This method returns a PolicyResults instance that can be passed to a reporting mechanism.

The ExamplePolicies class in the samples demonstrates how to do this.

Further reading

A more extensive blog post describing the implementation detail is available in my blog.

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (19)

Showing the top 5 NuGet packages that depend on NetArchTest.Rules:

Package Downloads

Package Description


C# Testing


This utility will only execute Architecture Tests.


This utility will only execute Architecture Tests.


This utility will only execute Architecture Tests.

GitHub repositories (7)

Showing the top 5 popular GitHub repositories that depend on NetArchTest.Rules:

Repository Stars
Full Modular Monolith application with Domain-Driven Design approach.
A .NET source generator for generating object mappings. No runtime reflection.
Full-stack .Net 8 Clean Architecture (Microservices, Modular Monolith, Monolith), Blazor, Angular 17, React 18, Vue 3, BFF with YARP, Domain-Driven Design, CQRS, SOLID, Asp.Net Core Identity Custom Storage, OpenID Connect, Entity Framework Core, Selenium, SignalR, Hosted Services, Health Checks, Rate Limiting, Cloud Services (Azure, AWS, Google)...
Navigate the complex landscape of .NET software architecture with our step-by-step, story-like guide. Unpack the interplay between modular monoliths, microservices, domain-driven design, and various architectural patterns. Go beyond the one-size-fits-all solutions and understand how to blend these approaches based on your unique needs.
Boilerplate of API in .NET 7
Version Downloads Last updated
1.3.2 1,639,257 5/23/2021
1.3.1 2,365 5/16/2021
1.3.0 138,193 10/29/2020
1.2.6 34,546 8/13/2020
1.2.5 85,001 3/6/2020
1.2.4 26,752 1/22/2020
1.2.3 75,332 10/21/2019
1.2.2 15,932 8/24/2019
1.2.1 15,345 7/1/2019
1.1.4 6,331 4/28/2019
1.1.3 1,431 3/22/2019
1.1.2 1,395 3/3/2019
1.1.1 3,153 12/27/2018
1.0.2 2,000 11/27/2018