SourceCrafter.DependencyInjection 2.26.286.181

SourceCrafter.DependencyInjection

Truly compile-time dependency injection for .NET. Services are declared with attributes and the Roslyn generator emits plain, readable C# resolvers — no reflection, no expression trees, no runtime container.

[ServiceProvider]
[Singleton<IClock, SystemClock>]
[Scoped<DbSession>]
[Transient<Handler>]
public partial class AppContainer { }

using var container = new AppContainer();
var handler = container.CreateScope().Handler;

Members are strongly typed by default, so an unresolvable service is a compile error. Opt into the generic IServiceProvider surface with [ServiceProvider(genericApi: true)] when the container has to be handed to code written against IServiceProvider: it emits real GetService<T>() / GetRequiredService<T>() members, keyed and async variants included, that dispatch by runtime type.

Full documentation lives in SourceCrafter.DependencyInjection/README.md — attribute reference, generated code walkthrough, cancellation semantics and the SCDI diagnostic table.

Packages

Repository layout

• SourceCrafter.DependencyInjection/ — the generator (netstandard2.0 is deliberately not targeted)
• SourceCrafter.DependencyInjection.Metadata/ — attribute definitions
• SourceCrafter.DependencyInjection.MsConfiguration*/ — configuration-aware variants
• SourceCrafter.DependencyInjection.Tests/ — the test suite
• Benchmarks/ — BenchmarkDotNet harness

Building and testing

dotnet build SourceCrafter.DependencyInjection.slnx

The test project targets .NET 10 and runs through the xUnit v3 in-process runner. dotnet test is currently unreliable with the .NET 10 SDK here, so run the produced executable directly:

dotnet build SourceCrafter.DependencyInjection.Tests/SourceCrafter.DependencyInjection.Tests.csproj
SourceCrafter.DependencyInjection.Tests/bin/Debug/net10.0/SourceCrafter.DependencyInjection.Tests.exe

Filter with -method "*SomePattern*".

Test layers

Changing the generator means keeping five different kinds of test honest:

• Tests.cs / Server.cs — behaviour. A realistic container is compiled by the real generator during the build, then exercised at runtime.
• GeneratedCodeTests.cs — emission. Runs the generator in memory via GeneratorHarness and asserts on the text it produces: lock scoping, the constructor, disposal ordering, file shape, and determinism across repeated passes.
• RootPropagationTests.cs — the Root/CreateScope virtual-dispatch contract.
• LockingStrategyTests.cs — the locking scheme itself, modelled by hand with no generator involved. Shows why one lock per lifetime deadlocks on cross-lifetime dependencies, why a single lock is correct but serializing, and why an instance lock cannot guard a static field.
• EqualityContractTests.cs — guards every generator model type against declaring Equals without a matching ==, which silently breaks incremental caching.

If you touch the emitter, GeneratedCodeTests is where a regression will surface first.

Inspecting generated output

dotnet build -p:EmitCompilerGeneratedFiles=true -p:CompilerGeneratedFilesOutputPath=obj/generated

Emit to a directory outside the project folder, or the generated files get picked up by the next compilation and every type ends up declared twice.

Benchmarks

Benchmarks/ compares this generator against every actively maintained compile-time DI container — Jab, Pure.DI, StrongInject and MrMeeseeks.DIE — following the scenarios that .NET Matrix has made the de facto standard for this category. Results are in the package README.

dotnet run -c Release --project Benchmarks -- --filter "*"

Two rules the harness must keep:

• Every branch does exactly the same work. An earlier version of this harness only built the container in the SourceCrafter branch while the others created a scope and resolved a service, so the published numbers compared nothing.
• Hand Coded is the baseline, not another container. Nested new(...) is the floor a compile-time container is trying to reach.

And one rule for reading the output:

• Do not publish a timing ratio from a single run. These scenarios resolve in tens of nanoseconds, where per-process JIT and heap-layout luck is a large fraction of the measurement. A single-launch run once showed all three containers jumping from ~38 ns to ~80 ns while the baseline held still — three independent libraries do not regress in lockstep. HarnessConfig therefore pins three process launches plus memory randomization, and even then the complex-graph scenario has been seen to vary 0.95x–2.10x across runs of the same binary with byte-identical allocations. Allocation counts are reproducible; sub-100 ns timings are only approximately so.

Where a library genuinely lacks a feature (StrongInject and MrMeeseeks.DIE have no request scope), the row is left empty rather than approximated: a made-up equivalent would measure something no user of that library could write.

Each container declaration lives in its own Containers.*.cs file, because the libraries ship attributes with colliding names ([Transient<,>], [Singleton<,>], [Scoped<,>], [Register]).

Contributing

Issues and pull requests are welcome. A few conventions that are not obvious from the code:

• The generator project sets EnableDefaultCompileItems=false. Any new .cs file must be added to the .csproj by hand, or it will silently not compile.
• Parsing and emission are separated on purpose. Anything reachable from a cached delegate must be free of ISymbol, SyntaxNode, SemanticModel and Compilation, otherwise the incremental pipeline keeps whole Roslyn compilations alive. ResolverRenderer is the frozen, symbol-free projection that the emitter renders from.
• New diagnostics go in ServiceContainerDiagnostics.cs with a fresh, unique SCDI id, and a DiagnosticDescriptor.Title that is static text (dynamic titles break IDE grouping).
• Generated code is normalized to tabs, CRLF and no trailing whitespace before it is emitted.

License

See LICENSE.txt.