BrixWare.Extensions.DynamicDependencyInjection.Loader 1.0.0

BrixWare Dynamic Dependency Injection (DDI)

A secondary DI container that runs alongside Microsoft's IServiceProvider at runtime. Enables dynamic registration and removal of services after BuildServiceProvider().

DDI is an extension of Microsoft's DI, not a replacement. It builds exclusively on Microsoft.Extensions.DependencyInjection.

Why DDI?

DDI was originally developed in 2024 to solve a concrete problem: integrating multiple AI providers and a growing set of plugins into a large .NET application — at runtime, without restarting the host. The providers and plugins changed frequently, each with its own dependencies, and the decision about which ones to load was driven by licensing, configuration, and even AI itself.

The technology has been stable and in production use since then. As someone who relies heavily on open-source software every day, publishing DDI is my way of giving something back to the community that has given me so much.

Switching to an alternative DI container was not an option. A large base of existing software is built on Microsoft's DI, and retrofitting it to a different container would have been impractical. DDI was therefore designed to extend Microsoft's DI — not replace it — so that existing code, registrations, and patterns remain completely untouched.

Three scenarios drove the design:

• Licensing constraints — certain modules may only be loaded if a valid license is present. The decision to load them happens at runtime, not at build time.
• Flexible runtime environments — assemblies need to be loaded, swapped, or unloaded without restarting the application. Think hot-reload for business logic, feature toggling at the assembly level, or multi-tenant setups where each tenant activates a different set of services.
• AI-driven component composition — modern applications increasingly assemble their behavior at runtime based on AI decisions: selecting the right model provider, loading a specialist agent, or wiring up tool implementations chosen dynamically. DDI makes it straightforward to register, replace, or remove these components on the fly — without a restart and without touching the rest of the application.
• Closing the gap with Python — Python developers take it for granted: load a module, instantiate a class, wire it into a running system — all at runtime, all dynamic. In .NET, the compiled and type-safe nature of the platform has traditionally made this kind of flexibility difficult. DDI brings that same dynamic capability to .NET — loading, composing, and executing objects within a managed lifecycle — without sacrificing the type safety, DI integration, and lifetime management that .NET developers expect.

Microsoft's built-in DI intentionally locks the container after BuildServiceProvider(). DDI solves exactly this gap: a secondary container that lives alongside the standard one and can be modified freely at runtime — including full support for dependency chains that mix DDI-registered and standard DI-registered services.

How DDI Compares

DryIoc supports Unregister() but has an expression-caching problem: deregistered services can remain inlined in cached resolution expressions. Services must be registered with Setup.With(asResolutionCall: true) to avoid stale references. DryIoc also replaces MS DI entirely rather than extending it.

Features

• Singleton, Transient, and Scoped lifetimes — full parity with Microsoft DI
• Keyed services — register and resolve services by key
• Factory-based registration — delegate factories for all lifetimes
• Cross-container resolution — DDI objects can depend on services from the parent DI container and vice versa
• DynamicActivator — custom constructor selection with automatic parameter resolution (DDI → DI fallback)
• Cascade invalidation — removing a service automatically invalidates all dependent singletons
• IDisposable handling — singletons and scoped instances are disposed when removed or when the scope/collection is disposed
• Diagnostics API — DependencyInfo provides dependency graphs, resolution status, and lifetime metadata
• TryAdd idempotent registration — TryAddSingleton, TryAddTransient, TryAddScoped for safe registration
• Scoped lifetime — CreateScope() creates isolated scopes with per-scope instance caching
• Multi-target — supports .NET Standard 2.0, .NET Standard 2.1, and .NET 10

Getting Started

Installation

# Core library
dotnet add package BrixWare.Extensions.DynamicDependencyInjection

# Optional: Assembly loader for plugin architectures
dotnet add package BrixWare.Extensions.DynamicDependencyInjection.Loader

1. Register the DDI container in your DI setup

var services = new ServiceCollection();

// Register your standard DI services
services.AddSingleton<ILogger, Logger>();

// Add the DDI container
services.AddDynamicServiceProvider();

var serviceProvider = services.BuildServiceProvider();

2. Register services dynamically at runtime

var ddi = serviceProvider.GetRequiredService<IDynamicServiceCollection>();

// Singleton
ddi.AddSingleton<ICache, InMemoryCache>();

// Transient
ddi.AddTransient<IRepository, DataRepository>();

// Scoped
ddi.AddScoped<IScopedCounter, ScopedCounter>();

// Factory-based
ddi.AddSingleton<IAuditService>(provider => new AuditService("created-by-factory"));

// Keyed
ddi.AddKeyedSingleton<IMessageSender, EmailSender>("email");
ddi.AddKeyedSingleton<IMessageSender, SmsSender>("sms");

3. Resolve services

var ddiProvider = serviceProvider.GetRequiredService<IDynamicServiceProvider>();

// Direct resolution
var cache = ddiProvider.GetRequiredService<ICache>();

// Keyed resolution
var emailSender = ddiProvider.GetKeyedService<IMessageSender>("email");

// Convenience extensions on IServiceProvider
var repo = serviceProvider.GetDynamicRequiredService<IRepository>();

4. Scoped lifetime

using var scope = ddiProvider.CreateScope();
var scopedProvider = scope.ServiceProvider;

var counter1 = scopedProvider.GetRequiredService<IScopedCounter>(); // new instance
var counter2 = scopedProvider.GetRequiredService<IScopedCounter>(); // same instance within scope

// Different scopes get different instances
using var scope2 = ddiProvider.CreateScope();
var counter3 = scope2.ServiceProvider.GetRequiredService<IScopedCounter>(); // different instance

5. Remove services dynamically

ddi.RemoveSingleton<ICache>();          // Removes and disposes cached instance
ddi.RemoveAll<IMessageSender>();        // Removes all lifetimes + keyed registrations
ddi.RemoveScoped<IScopedCounter>();     // Removes scoped registration

6. Dynamic assembly loading (Loader)

var ddi = serviceProvider.GetRequiredService<IDynamicServiceCollection>();

// Register a service from an external assembly at runtime
ddi.AddSingleton(
    instanceAssemblyPath: @"C:\plugins",
    instanceAssemblyName: "MyPlugin",
    instanceTypeName: "MyPlugin.Services.ReportGenerator",
    interfaceAssemblyPath: @"C:\plugins",
    interfaceAssemblyName: "MyPlugin.Abstractions",
    interfaceTypeName: "MyPlugin.Abstractions.IReportGenerator");

7. Diagnostics

var info = ddi.GetDependencyInfo<IRepository>();
// info.Dependencies  → [ILogger, ICache]
// info.Dependents    → [IOrderService]
// info.Lifetime      → Singleton
// info.IsResolved    → true/false
// info.IsFactory     → true/false

var allInfos = ddi.GetAllDependencyInfos();

Architecture

GetService<T>() / GetKeyedService<T>()
  → ResolveService() / ResolveKeyedService()
    → ResolveDescriptor()
      ├─ ResolveSingleton()  (caches result in ImplementationInstance)
      ├─ ResolveTransient()  (creates new instance each time)
      └─ ResolveScoped()     (caches per scope via DynamicServiceScope)
           ├─ InvokeFactory()       (delegate-based)
           └─ CreateFromDescriptor() → DynamicActivator.CreateInstance()
                └─ SelectBestConstructor() + InvokeConstructor()
                     (recursive parameter resolution with DDI → DI fallback)

Cross-Container Resolution

DDI objects can have constructor parameters from the parent DI container. The DynamicActivator automatically resolves parameters by checking:

1. DDI container (IsRegistered)
2. Parent DI container (IServiceProviderIsService or GetService)

This enables deep dependency chains across both containers:

PaymentService(DDI) → OrderService(DDI) → DataRepository(DDI) → ILogger(DI) + ICache(DDI)
                                        → NotificationService(DDI) → ILogger(DI)
                                        → IConfiguration(DI)

Project Structure

Target Frameworks

.NET Standard 2.0 ensures compatibility with .NET Framework 4.6.1+ and .NET Core 2.0+.

Core Types

Demo Applications

TestApp — ASP.NET Core Web API

A fully working ASP.NET Core demo with a pre-seeded SQLite database demonstrating the full DDI dependency chain.

cd src/BrixWare.TestApp
dotnet run

Then open https://localhost:{PORT}/scalar/v1 in your browser.

The demo database contains 7 pre-registered services:

Resetting the demo: Delete src/BrixWare.TestApp/demo.db and restart the app — it will be recreated and re-seeded automatically.

Key API Endpoints

AgentDemo — AI-Powered Runtime Code Generation

A CLI application that demonstrates the most advanced DDI use case: AI-generated .NET services compiled and registered at runtime.

cd src/BrixWare.DDI.AgentDemo
dotnet run

The demo uses Claude (Anthropic API) to generate C# code from natural language prompts, compiles it in-memory with Roslyn, and registers the resulting type in DDI — all without restarting the application.

Flow:

User Prompt
  → Claude API (C# code generation)
    → Roslyn CSharpCompilation (in-memory assembly)
      → DDI.AddKeyedSingleton (runtime registration)
        → GetService<IGeneratedService>() (resolve & execute)

Example prompts:

Simple — greeting with date/time:

Create a service that returns the current date and time formatted as a friendly
German greeting, like "Guten Morgen! Es ist Samstag, der 5. April 2026, 14:30 Uhr"

Algorithmic — Fibonacci with memoization:

Create a service that calculates the first 20 Fibonacci numbers and returns them
as a formatted table with index and value, e.g. "F(1) = 1, F(2) = 1, F(3) = 2..."

Visual — ASCII bar chart:

Create a service that generates ASCII art of a bar chart showing fictional monthly
revenue data for January through June 2026 with random values between 10000 and
50000. Include a legend and total sum at the bottom.

Note: The AgentDemo requires an Anthropic API key. This is a proof-of-concept to demonstrate DDI's dynamic capabilities. See the Security Disclaimer for important notes about runtime code execution.

Dependencies

Core Library

Loader

Security Disclaimer

DDI enables loading and registering arbitrary .NET assemblies and types at runtime. This is a powerful capability that introduces security responsibilities the caller must address.

By using this library you accept the following:

• Use at your own risk. DDI does not validate, authenticate, sign-check, or sandbox any assembly or type that is registered with it. It is the sole responsibility of the consuming application to ensure that only trusted, authorized assemblies are loaded.
• Implement your own security controls. Before passing an assembly path, type name, or factory delegate to DDI, the calling code must apply appropriate safeguards such as:
  • Verifying assembly signatures or strong names
  • Restricting allowed paths to known, controlled directories
  • Validating type names against an allowlist
  • Enforcing license and authorization checks prior to registration
• No warranty. This software is provided "as is", without warranty of any kind, express or implied. The authors and copyright holders are not liable for any claim, damages, or other liability arising from the use of this software or from loading assemblies through it.

The AgentDemo compiles and executes AI-generated code at runtime. This is inherently risky and intended as a proof-of-concept only. Never run AI-generated code in production without proper sandboxing and review.

The MIT license under which this software is distributed already excludes all warranties and liability to the maximum extent permitted by applicable law. This section makes the runtime-loading risk explicit so that integrators are aware of it before deployment.

Contributing

Contributions are welcome! Please read the Contributing Guide for details on how to submit pull requests, report issues, and contribute to the project.

License

MIT — Copyright © 2025 BrixWare — Janusch Koza