For the standard web page lifecycle it's fine, but for instances like this it really does become fiddly.
But often it's possible, but often a ideological stance the framework team have taken that leads to a poor documentation issue.
The asp.net core team have some weird hills they die on, and some incredibly poor designs that stem from an over adherence to trendy patterns. It often feels they don't understand why those patterns exists.
This results in them hardly documentating how to use the DI outside of their 'ideal' flow.
They also try and push devs to use DI for injecting config. Which no other language does and is just unnecessarily complicated. And it's ended up with a system no-one really understands while the old System.Configuration, while clunky, at least automatically rebooted the app when you edited the config. Which is the 95% use case most devs would want.
FWIW, when I thought about it in the larger enterprise context, I realized that I also hold a seemingly opposite view. I presented that elsewhere in this thread:
TL;DR: the goal of enterprise frameworks isn't to make Perfect Software Framework or to make code beautiful, devoid of bloat, or even easy. Their goal is to make programming consistent and predictable, to make programmers exchangeable. It's to allow an average developer to churn around working results at a predictable pace, as long as the project is just standard stuff, and they don't bring their own opinions into it. Large businesses want things this way, because that's how they think about everything (see also: Seeing Like a State).
Of course, this doesn't mean the framework authors succeed at that goal either :). Some decisions are plain stupid. But less than one would think.
For the standard web page lifecycle it's fine, but for instances like this it really does become fiddly.
But often it's possible, but often a ideological stance the framework team have taken that leads to a poor documentation issue.
The asp.net core team have some weird hills they die on, and some incredibly poor designs that stem from an over adherence to trendy patterns. It often feels they don't understand why those patterns exists.
This results in them hardly documentating how to use the DI outside of their 'ideal' flow.
They also try and push devs to use DI for injecting config. Which no other language does and is just unnecessarily complicated. And it's ended up with a system no-one really understands while the old System.Configuration, while clunky, at least automatically rebooted the app when you edited the config. Which is the 95% use case most devs would want.