[OutputCaching] OutputCacheOptions.ApplicationServices
is always null
during initialization
#55805
Open
1 task done
Labels
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
feature-output-caching
Is there an existing issue for this?
Describe the bug
When configuring output caching using a configuration action, the
ApplicationServices
is not populated in time to be used by the action. This leads into an extremely unintuitive and noob-unfriendly API.This happens because the
ApplicationServices
property is itself initialized using a customIConfigureOptions
implementation that is only added after the provided configuration delegate.I think this design is not only unfriendly (as you now have a property that is only initialized in some circumstances) but hard to understand: why even add this property in the first place if whoever is configuring this option from the outside could just use another
IConfigureOptions
implementation themselves, or even call the various.AddOptions<T>.Configure<TDep...>
overloads which are made for the purpose of using container dependencies to configure some given options?Either the property should guarantee it's API (thus never be
null
), or it should be entirely removed and consumers should leverage existing mechanisms to perform configuration using dependencies.The fact that this works makes little sense to me and should not be encouraged:
At this point, I'd honestly rather do this which is much more idiomatic unless I'm missing something substantial:
Which, again, completely defeats the purpose of this
ApplicationServices
property existing in the first place.Expected Behavior
Many different behaviors could be possible here I think.
Make sure
ApplicationServices
is nevernull
. This would probably be only a matter of swapping the order of these 2 statements here:aspnetcore/src/Middleware/OutputCaching/src/OutputCacheServiceCollectionExtensions.cs
Lines 53 to 54 in 94ad1d4
Remove
ApplicationServices
property altogether and have consumers rely on more standard strategies to leverage DI for configurationWhile I think 1 is much easier, I would honestly suggest 2 as a better long-term solution that would lead people into the pit of success more often and result in more idiomatic configuration code.
Steps To Reproduce
IServiceCollection.AddOutputCache(Action<OutputCacheOptions>)
overloadApplicationServices
property on the passed-inoptions
objectFull repro project:
Exceptions (if any)
.NET Version
net8.0
Anything else?
No response
The text was updated successfully, but these errors were encountered: