DiPolicy.Source 0.0.1

DI Policy

Keep your .NET dependency injection setup consistent, reviewable, and enforceable.

DI Policy lets you define architectural DI rules once and verify them automatically in tests or CI.

Why Teams Use It

• Catch DI structure regressions early
• Make architecture rules executable instead of tribal knowledge
• Get actionable failure messages when rules are violated
• Reuse rule checks across teams and services

What You Get

• Fluent policy DSL (That, Must, Because, ExceptFor)
• Extraction from real registration methods
• Evaluation engine with normalized violations
• NUnit and xUnit integrations
• Auto-fixer engine + dipolicy CLI
• Fully extensible filters/assertions
• Practical built-in starter rules from DiPolicy.Rules

Quick Start

Install testing integration (includes DSL + extraction dependencies):

dotnet add package DiPolicy.NUnit

or

dotnet add package DiPolicy.Xunit

Both testing packages include the built-in rule library (DiPolicy.Rules) by default.

Example (from the sample style):

using DiPolicy;

Action<IServiceCollection> registration = MyCompositionRoot.Register;

registration.Services
    .That.AreShared
    .Must.BeRegisteredIdempotently
    .ShouldBeSatisfied();

Extensible by Design

• Add your own filters by implementing IRuleFilter<TSubject> (or typed variants).
• Add your own assertions by implementing IRuleAssertion<TSubject> (or typed variants).
• Fluent members are generated for these implementations and become part of your policy language.

Built-In Starter Rules

• The repository already ships many practical filters/assertions used in real scenarios.
• They are packaged in DiPolicy.Rules.
• DiPolicy.NUnit and DiPolicy.Xunit include DiPolicy.Rules transitively.

Package Overview

• DiPolicy.Abstractions: core contracts for subjects, filters, assertions, violations
• DiPolicy.Model: immutable internal rule model (Rule, invocations, exceptions)
• DiPolicy.Engine: evaluation and violation message formatting
• DiPolicy.Dsl: fluent rule stages (That, Must, Because, ExceptFor, Evaluate)
• DiPolicy.Extraction: subject extraction from registration delegates
• DiPolicy.Generator: source generation for fluent filter/assertion extensions
• DiPolicy.Rules: built-in filters/assertions for common DI structure checks
• DiPolicy.NUnit / DiPolicy.Xunit: test-framework integrations
• DiPolicy.Fixes / DiPolicy.Tool: auto-fix engine and CLI tool

Auto-Fixer CLI

Pack and install locally:

dotnet pack src/DiPolicy.Fixes.Cli/DiPolicy.Fixes.Cli.csproj -c Release
dotnet tool install -g DiPolicy.Tool --add-source src/DiPolicy.Fixes.Cli/bin/Release

Run all DiPolicy-enabled failing tests in a project and apply discovered fixes:

dipolicy fix --project <path-to-folder-or-project>

or:

dipolicy fix <path-to-folder-or-project>

or (rule-driven payload directly from test output):

dipolicy fix --payload <base64-json>

If no arguments are provided, dipolicy prompts interactively for project path first, then payload token.

Notes:

• Additional method parameters are replayed from payload arguments
• IConfiguration can be passed as key=value;key2=value2
• If IConfiguration is left empty, dipolicy auto-loads nearest appsettings*.json (relative to the target assembly) and environment variables
• --payload is a self-contained Base64 JSON payload (CI-friendly copy/paste)
• --from still supports reading a JSON file payload and deletes it after loading (best effort)
• Auto-fix is assertion-driven and target-state based (IRuleTargetStateAssertion)
• The fluent DSL stays unchanged externally (That...Must...And...ShouldBeSatisfied()), while fixes are derived from declarative target-state clauses under the hood
• Target-state clauses are compiled to executable operations in the fixer pipeline
• Built-in rules provide operation-specific executors/engines (per assertion intent), while the core rewriter stays generic
• Target-state clauses can carry explicit preferences (for example shared-dependency promotion and ordering intent)
• CLI discovers IFixOperationExecutor implementations from the target assembly and its references (plugin-friendly, no hard Rules coupling)

Payload shape:

{
  "assemblyPath": "/path/to/YourAssembly.dll",
  "typeNameMethodName": "Your.Namespace.Type.Register",
  "arguments": [
    { "format": "ConfigurationJson", "value": "{\"My:Key\":\"Value\"}" }
  ],
  "assertionViolations": [
    {
      "assertionName": "RegisterNonSharedDependencies",
      "violatingUseCaseNames": ["Your.Namespace.Type.RegisterSomething"],
      "violatingServiceNames": ["Your.Namespace.IYourService"],
      "violatingServiceKeys": ["Your.Namespace.IYourService|...|..."],
      "targetStateClauses": [
        {
          "kind": "RegistrationMethodName",
          "preferences": {
            "promoteSharedDependencies": false,
            "ordering": "Preserve"
          },
          "directives": [
            { "kind": "UseCaseName", "value": "Your.Namespace.Type.RegisterSomething" }
          ]
        }
      ]
    }
  ]
}

Validation messages include a Rule assertion: <file>:<line>:<column> hint so you can jump directly to the concrete fluent assertion in your policy.

Requirements

• .NET SDK from global.json (10.0.100)
• C# 14 language features are used in this repository

Documentation

• Core Concepts
• Subjects
• Filters
• Assertions
• Fluent DSL Overview
• Execution and Violations
• Testing Integrations
• Detailed DSL Docs