Enable Scrutor to use external DI

[pfeigl]

We had DI running for quite some time now using the standard microsoft implementation. Due to several reasons (one beeing dotnet/aspnetcore#2737) we now move to SimpleInjector (which we used on legacy WebApi projects alot).

Now SimpleInjector does not have rich assembly scanning support and states

Although many other DI libraries contain an advanced API for doing convention based registration, we found that doing this with custom LINQ queries is easier to write, more understandable, and can often prove to be more flexible than using a predefined and restrictive API.

I can totally accept this, however we are now sitting infront of quite some Scrutor lines which did this heavy lifting for us.

Something that would now have been really cool is to still be able to use Scrutor but inject a custom RegistrationStrategy which under the hood would not do services.Add but instead a custom action like container.Register. (SimpleInjector even has some code under the hood which turns ServiceDescriptor objects into SImpleInjector registrations).

Does this make any sense or is it completely out of the scope of this project?

Thanks,
Philipp

[khellang]

Hey @pfeigl! 👋

I'm not super stoked about the idea of tearing this library in two — one part for scanning and another one for registering.

Now, if you can live with the dependency on MS.Ext.DI, I don't think I have a problem with adding a way to override the registration mechanism. Could be as simple as providing a delegate somewhere.

Another thing you could do is just new up a ServiceCollection, use Scrutor for scanning, then loop over the ServiceDescriptors and inject those into SimpleInjector, then throw it away without creating a provider.

You could even tuck all of that away in a nice extension method on your SimpleInjector container if you want.

What do you think? Would that work? 🤔

[khellang]

Something like this seems to work, but it's a really simple example so I have no clue how well it works for a Real World App™.

using System;
using Microsoft.Extensions.DependencyInjection;
using Scrutor;
using SimpleInjector;

public class Program
{
    public static void Main(string[] args)
    {
        var container = new Container();

        container.Options.DefaultScopedLifestyle = ScopedLifestyle.Flowing;

        container.Scan(scan =>scan
            .FromAssemblyOf<Program>()
                .AddClasses(classes => classes.AssignableTo<IService>())
                .AsImplementedInterfaces()
                .WithSingletonLifetime());

        var service = container.GetInstance<IService>();
    }
}

public interface IService  {  }

public class ServiceA : IService  { }

public class ServiceB : IService { }

public static class ContainerExtensions
{
    public static void Scan(this Container container, Action<ITypeSourceSelector> selector)
    {
        var services = new ServiceCollection();

        services.EnableSimpleInjectorCrossWiring(container);

        services.Scan(selector);

        var provider = services.BuildServiceProvider();

        container.AutoCrossWireAspNetComponents(provider);
    }
}

[khellang]

It doesn't seem to work well for collections, as SimpleInjector requires explicit collection registration, while MS.Ext.DI allows you to "append" multiple registrations and resolve them as a collection.

[pfeigl]

Hi @khellang ,

sometimes .... you just don't see the forest for the trees anymore :-)

Using the CrossWiring directly is a very neat integration but fails on collections as you already realized.
I guess I'm going to do the ServiceDescriptor <-> SimpleInjector Registration conversion on my own. That what I can easily check for multiple registrations on the same interfaces and register those as collections.

I even realized that my initial idea would work out of the box, because I completely missed the UsingRegistrationStrategy call which would allow me to have a SimpleInjectorRegistrationStrategy. However this again falls short on the collections because I'd handle the reported ServiceDescriptors one-by-one.

Anyways, big thanks and shoutout to your clever ideas and this super cool project. I guess with all those options available, there is no need to apply any changes to scrutor, because everythings there already 👍

[pfeigl]

I also looked into AutoCrossWireAspNetComponents and while I understand, that it has to be the way it is for the real MS.Ext.DI wiring, the fact that it internally generates registrations within the ResolveUnregisteredType event seems semi-optimal for the normal dependency resolving and offloads work to a step in the execution pipeline, where it shouldn't be required.

So I think build up the container completely by iterating a new ServiceCollection right in the Startup seems to be the best option IMHO.

[pfeigl]

This is btw. what seems to work ok for now for us. There is quite a few cases not considered here (which were not relevant to us).

• Collection registrations use the Lifestyle of the first identified collection item
• Only registrations based on ImplementationType do work (We did not use anything else like factories - atleast not via Scrutor)

var processedCollections = new List<Type>();
foreach(var descriptor in services)
{
	Lifestyle lifestyle;
	switch (descriptor.Lifetime)
	{
		case ServiceLifetime.Scoped:
			lifestyle = Lifestyle.Scoped;
			break;
		case ServiceLifetime.Singleton:
			lifestyle = Lifestyle.Singleton;
			break;
		case ServiceLifetime.Transient:
		default:
			lifestyle = Lifestyle.Transient;
			break;
	}

	if (services.Any(d => d != descriptor && d.ServiceType == descriptor.ServiceType))
	{
		if(processedCollections.Contains(descriptor.ServiceType))
		{
			continue;
		}
		Container.Collection.Register(descriptor.ServiceType, services
			.Where(d => d.ServiceType == descriptor.ServiceType)
			.Select(d => lifestyle.CreateRegistration(d.ImplementationType, Container)));
		processedCollections.Add(descriptor.ServiceType);
	}
	else
	{
		Container.Register(descriptor.ServiceType, descriptor.ImplementationType, lifestyle);
	}
}

[pfeigl]

Closing - thanks for the help, everything worked out today just nicely.