Constructor selection

[jovball]

We are getting started with Wolverine and just ran into a major roadblock for us. We are running .NET 10 with EF Core and minimal APIs. Some of our classes have multiple constructors, typically a partial class that was generated with "core" constructors like ILogger and a DbContext and then those constructors have been extended in another partial class. Wolverine always seems to choose the constructor that has the fewest arguments and then the other objects are null and throw an exception. We have tried a few things like [DefaultConstructor] and nothing has worked.

How should we be handling this?

[jeremydmiller]

"How should we be handling this?" -- don't do that is my best suggestion. And I say that too as the author of the original production worthy IoC container in .NET as well as being the tech lead of Wolverine. [DefaultConstructor] would be a Lamar thing. I guess we could adopt a version of that in the JasperFx pieces.

Switching this to a Discussion

[jovball]

The current behavior for Microsoft DI and also for Lamar is to use the greediest constructor, or at least the greediest reachable. Why would Wolverine go the other way?

https://jasperfx.github.io/lamar/documentation/ioc/registration/constructor-selection/

[jeremydmiller]

Because I'm not perfectly omniscient and "I take pull requests". It probably would work as is with the old Lamar integration because in that case Wolverine just uses Lamar's planning.

[jovball]

Jeremy:

I should've started the discussion by saying that Wolverine has many strengths, and I've been appreciating what it can do. I'm working to get a support plan for our agency.

My previous comment doesn't read well in hindsight. It comes off as an entitled "why don't you give me what I want" and some of that might be true. But also, I'm still learning how to use Wolverine and always still learning how to create better software. I know that I don't do some things like I did 10 years ago. I know that it's not necessarily right just because Microsoft does it that way.

Combining those things with your response, help me understand if you were making a deliberate design decision (what your first response implies) or if it was YAGNI or you had more important features to build. If it was a deliberate design decision, I'd like to understand it more.

Thanks again

[jeremydmiller]

To be honest, Wolverine quite intentionally -- sometimes with negative consequences -- deviated from mainstream .NET by insisting on simplistic DI usage to best utilize what Wolverine does. The root problem is that Wolverine is trying to utilize the DI configuration to "know" how to generate code to replicate the DI container, but in hard coded, inlined code. Awesome when it works, kind of a bear with more runtime IoC usage.

I'll buy that this is something we could deal with. TBH, as an old IoC guy, I hated the greediest constructor logic thing and never recommended that until MS came along and unilaterally redefined how everything was supposed to work w/o any involvement from any of us in the OSS community

[jovball]

We changed how we are generating that constructor so we have a workable solution. Not sure I'm in love with it but it's not a roadblock as of now.