Implement factory pattern for classes requiring both DI services and runtime arguments

[kristoffer-tungland]

Background

DependencyInjection.SourceGenerator currently generates registration code based on the [Register] attribute.
This works well for services where all constructor parameters can be resolved directly from the DI container.

However, some services require runtime values — such as IDs, file paths, or user-provided options — in addition to their injected dependencies.
In these cases, the generator currently produces registrations that fail at runtime, because the DI framework cannot provide those parameters automatically.

Problem

When a service constructor includes both DI-resolvable dependencies and parameters that must be supplied at runtime, the generator has no way to distinguish between them.
This means developers must currently:

• Manually write a factory class that combines DI and runtime arguments, or
• Add an Initialize(...) method and perform a two-step construction.

Both approaches are inconsistent with the library’s goal of compile-time verified, single-phase registration.

Goal

Extend the source generator to support factory generation for services whose constructors include parameters that cannot be resolved from DI.
The goal is to let the generator automatically produce a factory that:

• Resolves DI dependencies using the container,
• Accepts runtime arguments explicitly,
• And returns a fully constructed instance of the target type.

The generated factory should always be registered as a singleton, since it only acts as a creation helper and has no per-instance state.

Concept

Developers would be able to mark specific constructor parameters to indicate that they should not be resolved from DI.
The generator would then:

1. Detect constructors containing both DI and non-DI parameters.
2. Generate a strongly-typed factory (interface + implementation, and optionally a delegate).
3. Register the factory as a singleton service alongside the existing DI registrations.

The factory would internally use ActivatorUtilities.CreateInstance(...) (for Microsoft DI) or the equivalent for LightInject to combine container-resolved services with the runtime parameters.

Example scenario

[Register(typeof(IReportJob), Lifetime.Scoped)]
public sealed class ReportJob : IReportJob
{
    public ReportJob(IRepository repository,
                     ILogger<ReportJob> logger,
                     [FactoryArgument] Guid reportId)
    {
        ...
    }
}

Generated conceptually:

public interface IReportJobFactory
{
    IReportJob Create(Guid reportId);
}

[GeneratedCode("DependencyInjection.SourceGenerator", "1.0.0.0")]
public sealed class ReportJobFactory : IReportJobFactory
{
    private readonly IServiceProvider _sp;
    public ReportJobFactory(IServiceProvider sp) => _sp = sp;

    public IReportJob Create(Guid reportId) =>
        ActivatorUtilities.CreateInstance<ReportJob>(_sp, reportId);
}

// Registration
services.AddSingleton<IReportJobFactory, ReportJobFactory>();

Summary

This feature will make DependencyInjection.SourceGenerator more robust by allowing automatic factory generation for services that depend on both:

• Regular DI-injected services, and
• Explicit runtime arguments.

It eliminates the need for manual factories or post-construction initialization,
and ensures consistent, compile-time generated DI registration — even for mixed constructor scenarios.

All generated factories will be singleton by design.

[kristoffer-tungland]

---

💬 Additional Notes: Delegate-Based Factories

A delegate factory is a lightweight alternative to an interface-based factory.
Instead of generating an interface and implementation, the generator can emit a simple delegate type that represents a creation function.

For example, instead of:

public interface IReportJobFactory
{
    IReportJob Create(Guid reportId);
}

The generator can emit:

public delegate IReportJob ReportJobFactory(Guid reportId);

This allows consumers to inject and call the factory as a function:

public sealed class ReportManager
{
    private readonly ReportJobFactory _createReportJob;

    public ReportManager(ReportJobFactory createReportJob)
    {
        _createReportJob = createReportJob;
    }

    public async Task RunAsync(Guid reportId)
    {
        var job = _createReportJob(reportId);
        await job.ExecuteAsync();
    }
}

The DI registration for Microsoft.Extensions.DependencyInjection would look like:

services.AddTransient<ReportJobFactory>(sp =>
    (Guid reportId) => ActivatorUtilities.CreateInstance<ReportJob>(sp, reportId));

This delegate acts as a strongly-typed factory method, letting consumers directly create instances without an explicit factory class.
It’s concise, requires no interface or implementation, and integrates seamlessly with DI.

Pattern	Description	Pros	Typical Use
Interface Factory	Generator emits an interface and implementation class.	Explicit type, extensible, mockable in tests.	Public APIs, testable components.
Delegate Factory	Generator emits a simple delegate (function type).	Lightweight, minimal code, injects like a function.	Internal factories, lightweight services.

In most cases, the generated factory can be registered as both an interface-based factory and a delegate factory for developer convenience.

[frte-cowi]

Use ActivatorUtilities.CreateFactory and cache it
CreateFactory produces an ObjectFactory delegate that’s much faster than reflection-per-call and lets you pass the runtime args array. Emit a static cached field per target:

internal static class ReportJob_FactoryCache
{
    public static readonly ObjectFactory ObjectFactory =
        ActivatorUtilities.CreateFactory(typeof(ReportJob), new[] { typeof(Guid) });
}