The latest updates on your projects. Learn more about Vercel for Git ↗︎

@migus88 I encountered a problem, multiple registration for single interface does not work as expected. Inject IEnumerable will always contain zero elements if the method with ID was used.

@softshadedev thanks, I will take a look at it!
Probably this scenario isn't covered by unit tests - will add them as well.

I also want to see how I can move the registration with ID to use the FixedTypeKeyHashtable instead of dictionary and to merge the functionalities. This should also solve the issue you've mentioned.

Well, on my side - it passed all checks I wanted it to pass and the PR is now ready.
@hadashiA, I would appreciate a review.

I understand that this is a huge PR and it takes time.
Maybe we can start by running the rest of the tests and in case something's wrong I'll fix it?

@migus88
Thank you very much for your hard work.
There are benchmarks, and the quality seems to be fine.

I am positive about merging it.

There are two reasons for the delayed response.

First, I have less time to devote to this project. I apologize for keeping you waiting.

Second, as I've mentioned in previous issues, I've been somewhat hesitant about this feature.
#218 (comment)

I have been considering this PR and the feedback.
Now that the user base has grown and Microsoft.Extensions.DI has added similar functionality, the situation has changed.
Additionally, it seems that most people other than myself are in favor of this feature.

Therefore, I plan to merge it in principle.
This is a major feature, so I'd like to think about whether this API is appropriate.
Thank you very much!

Hey @hadashiA, first of all - huge thanks for the fantastic work you’re doing. I completely understand your reasons for taking the time on this PR.
Please, don't hesitate to comment here, or even in private - I’d be happy to collaborate on adapting this feature so it aligns well with the project’s needs.

On a personal note: a few years back, I was in a similar position. Initially, I was skeptical too - but working in an environment where this approach was heavily used helped me grow to really like it. At the end of the day, almost any pattern can be abused, but that alone shouldn’t disqualify its potential when applied thoughtfully. 🙂

Apologize for the delayed response ><

I would like to request two corrections regarding the public API.

1. This feature uses the term “Id,” but I would prefer the name “Key.”
   • Microsoft.Extensions is currently the standard library in C#, and it uses the name “KeyedService.”
     • https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-9.0#keyed-services
   • VContainer initially referenced AutoFac, which also uses the name KeyedService.
     • https://autofac.readthedocs.io/en/latest/advanced/keyed-services.html#keyed-services
   • So, in C#, Key is generally considered the standard term I think.
2. I want to use a different attribute than [Inject] to specify the key.
   • [Inejct(Id = ...)] is easy to understand as DI, but I think it becomes a little difficult to use when there are multiple uses. Also, the Inject attribute currently means “method/ctor where Inject is automatically executed.” I think it would be clearer not to give it another meaning.

Based on the above, my proposal is as follows.

// Registration
builder.RegisterType<Weapon>().Keyed(SomeEnum.Primary);

// Constructor Injection
public SomeClass(
    [Key(SomeEntry.Primary)]  Weapon primaryWeapon
)
{
    // ...
}

I welcome any other opinions or counterarguments.
I would appreciate your confirmation. Thanks!

I’m not sure about the name Keyed — it doesn’t sound quite right to me. Maybe something like WithKey would feel more intuitive?
That said, it’s definitely not a deal breaker, especially if Keyed is becoming a sort of convention.

Regarding KeyAttribute — I’m generally fine with it, but Key feels a bit too generic. I can imagine it clashing with existing code in some projects.
Maybe something like InjectKey or a similarly specific name would be safer?

@hadashiA anyway, I've pushed the change both with KeyAttribute and Keyed method name.
Also added the documentation to the website.

@migus88 Thanks for the quick response on this!
Sorry for making you revise it multiple times!

I'm not sure about the name Keyed — it doesn't sound quite right to me. Maybe something like WithKey would feel more intuitive?

You're probably right that WithKey is more straightforward and easier to understand.
I'm actually a bit torn on this point myself.
But as you said, the term Keyed is used fairly often, so either one seems fine to me. Actually, Keyed() is borrowed from Autofac.
Since you've already made the changes with Keyed, I'd like to go with this!

I'm generally fine with it, but Key feels a bit too generic.

Fair point here too, but I personally prefer the conciseness of [Key].
You're right that InjectKey is clearer. But for attributes that get specified multiple times at the field or parameter level, I think it's worth prioritizing visual clarity and conciseness in the declarations.
Actually, System.ComponentModel.DataAnnotations and MessagePack-CSharp both use [Key] as their attribute name.
There's always the risk of naming conflicts, but we have namespaces for that.

Anyway, thanks again for the quick fixes! I'm happy with the API as it is now. I'll do a quick check to make sure there aren't any major functional issues and then merge it.

Merged. Thanks so much.
I might make some tweaks to the documentation later, just a heads up.

Awesome news!!! Thanks!