Here is the common pattern we have:
The problem is now that this is simply becoming unwieldy. too much is pushed to the runtime to break (in particular: when it actually gets run).
The only thing I can think of is to move more and more things into modules, and potentially moving all of the AppSetting reading into dedicated classes which do the reading itself in the constructor.
These can then be injected in (as an interface) to the places they are actually required.. Rather than relying on the WithParameter option when registering the type with autofac
There 4-5 such files in the solution (each in a separate project.. Different APIs basically). The largest is 3k lines long (and of course does make use of modules.. But some of those lines are the reading of config values or just registering types directly in the class, and outside modules).
How would others structure this?
Personally, I’m a big fan of the Spring-style registration via assembly scanning. I prefer to just add an attribute to classes that should be registered and have them be discovered automatically by the DI container — it makes things much less error-prone and easier on the long run in my experience.
C# devs
null reference exceptions