themesof.net VS Scrutor

This is a good one, though it's more vague then a typical roadmap https://themesof.net/

Right, so, if we're going to talk about unreleased, future features, then I have a little roadmap here to show you.

The dotnet team at least does use it in a number of stuff. Tye's dashboard UI uses Blazor server, and if I recall some parts of MS docs uses Blazor WASM to evaluate C# code in the browser. dotnet live and https://themesof.net/ uses Blazor server as well.

Having said that, charting is a very basic and fundamental enterprise application requirement, so we do support that. As a matter of fact we have an entire project theme (inspired from https://themesof.net/) dedicated to enterprise solution requirements, including lot of stuff from async queue-based or batch processing to allowing the end user to define their own queries and exporting results to excel and the like.

What you call "meme", I call .NET appeals to net-new developers, students, and new technologists, which is one of the Themes of .NET, which guide the platform, languages, and tooling roadmap.

There’s more information on the plans, changes, and challenges encountered with the current .NET 6 development on Microsoft’s Themes of .NET.

You can with MS's default DI as well via scrutor.

if you are heavily invested in autofac you can replace the build in DI with another container. at this point i don't think it is that necessary. especially if you use scrutor. it gives your some nice assembly scanning registration that autofac/simple injector give https://github.com/khellang/Scrutor

If you wouldn't mind, I have one additional question. If I wouldn't bother to remove this loading, how could one add that as service when using DI? I have found tool called Scrutor (https://github.com/khellang/Scrutor), is it something commonly used in situation like this?

I much prefer using Scrutor and asbly scanning myself. https://github.com/khellang/Scrutor

you can also use Scrutor to get closer to Autofac functionality https://github.com/khellang/Scrutor

That can't be the only justification, because you can easily register services using reflection without using MediatR.

I might suggest additional registration time extensions to modify the behavior as needed on classes. Take a look at Scrutor for some inspiration on API specifically.

There is a package that simplifies it for you if you want. But not everybody agrees that automatic registration is good pattern, so you have a choice.