Codecov Report

Attention: Patch coverage is 70.49180% with 36 lines in your changes missing coverage. Please review.

Project coverage is 66.15%. Comparing base (a634e58) to head (7fcedf7).
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master     #209      +/-   ##
==========================================
+ Coverage   64.71%   66.15%   +1.44%     
==========================================
  Files          25       24       -1     
  Lines        1278     1232      -46     
  Branches        0      112     +112     
==========================================
- Hits          827      815      -12     
+ Misses        451      387      -64     
- Partials        0       30      +30     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for the review, @DanHarltey! All good feedback 👍🏻

Hi @khellang
When this will be available at the nuget package? We really need this. 😃

Please, please, please :)

PS
We are doing future project but as for now we are using NET8 RC2. Before our release we are switching to full NET8 ofcoz. 😄

I can probably target RC2 and publish a prerelease version if anyone's eager to test it out.

I can probably target RC2 and publish a prerelease version if anyone's eager to test it out.

@khellang Yes please 🙏🏻

Hi @khellang 😃
I'm just cloned branch for net8 and adopted source code into my project. 😄

Now I can wait for released version of net8 and newest scrutor 😃
I hope that Scan will have appropriate extensions for keyed services also. 👍🏻
Thanks for help. ❤️

I hope that Scan will have appropriate extensions for keyed services also. 👍🏻

What does that mean? How do you envision using keyed services with Scrutor?

I hope that Scan will have appropriate extensions for keyed services also. 👍🏻

What does that mean? How do you envision using keyed services with Scrutor?

I would love to register services from given assembly as keyed with specified key,

For example. I have modular monolith. Each module is a separated project/assembly. I execute services.Scan(...) to register all ICommandHandler from that assembly. I want to register them as keyed services. Thanks to that I can resolve only those services in particular module.

For now I am using this hacky solution 😄

        var tempServices = new ServiceCollection();

        tempServices.Scan(  );
        
        foreach (var service in tempServices)
        {
                // register service as keyed
        }

It would be great to do this something like:

new ServiceCollection()
            .Scan(s => s.FromAssembliesOf(module.GetType())
                .AddClasses(c =>
                {
                    c.AssignableToAny(
                            typeof(ICommandHandler<,>),
                            typeof(ICommandHandler<>),
                            typeof(IQueryHandler<,>),
                            typeof(IEventHandler<>),
                            typeof(IDomainEventHandler<>))
                        .WithoutAttribute<DecoratorAttribute>();
                }, false)
                .AsKeyed(moduleName) //  <========
                .AsImplementedInterfaces()
                .WithScopedLifetime());

If it's allowed to register multiple services against the same key, it could work. I'll have to verify it.

Hi @khellang :)
How about this? Will be any chance for this? 😃

Hi @khellang ?

How about now, after NET8 premiere? 😄

Still waiting :)

@rekosko What exactly are you waiting for? The latest version on NuGet works fine on .NET 8, right?

@khellang yes I confirm it works on .NET 8 :) But decoration for keyed services is not yet implemented or I missed the purpose of this PR?

That's not the purpose of this PR, no. Although I want to add that as well before shipping a new version. This PR replaces an old hack to avoid StackOverflowExceptions when decorating services with keyed services under the covers. It also files a few other long-standing issues and pending breaking changes.

BTW, if anyone wants to contribute support for decorating keyed services to get a release out sooner, that would be cool.

@khellang Can this be merged into master or it's not complete or it needs more testing? Or it's better to base all the tests and work on feature/net8.0 branch?

It's not totally complete and needs more tests. It's better to base work off this branch for now. Once this goes into master, I will release a new major version.

Gentle ping on this. I wonder what's the plan/fate for this PR?

Howdy! Will Scrutor be ported to .NET 8?
.NET 6 is getting very close to its End of Support deadline.

Will Scrutor be ported to .NET 8? .NET 6 is getting very close to its End of Support deadline.

Just because the library targets .NET 6, doesn't mean it doesn't support .NET 8. It's perfectly fine to use packages targeting older framework versions on newer frameworks.

Have you encountered any issues using the package on .NET 8?

Everyone, I've gone ahead and merged this and released v5.0.0 to NuGet. Please try it out and report back if you find any issues 🙏🏻 Thanks for your patience 😊

Is there an example somewhere how to perform 'keyed registrations' using the latest Scrutor version? TIA

As mentioned in #209 (comment), this isn't adding support for keyed registrations, it's merely (ab)using them internally to avoid StackOverflowExceptions when doing decoration 😄

If someone is up to the task to implement support for keyed registrations, I'd love to see it ❤️

Do you have any thoughts on what it would look like, @ThumbGen?

Thanks for the fast reply. Sadly I have no thoughts on it, I am just an avid consumer of this lovely library :-(

@khellang I saw this PR mentioned in the 5.0.1 release notes and just wanted to make sure I get this right: this change is just to rely on keyed service capabilities internally, but it results in the exact same behavior as before, including all the limitations that existed before. Is that a valid way of putting it?

If not, could you elaborate on what this could end up changing or what limitations it removes in terms of using decorators?

Is that a valid way of putting it?

@julealgon That's correct, yes. Earlier, we relied internally on a huge hack to make decoration work, which ended up breaking a few scenarios, like Azure Functions. This PR replace that solution with a less hacky solution based on keyed services.

There is a potential benefit of this, which is that you could resolved a keyed service to get a hold of the "original", wrapped, service, but that hasn't been tested fully.