Review all middleware options usage about options

[divega]

Should we also have the empty overload of UseXyz() to pull options from DI without touching them?

[HaoK]

The base class doesn't work well, I tried that option and it fails miserably with AuthenticationOptions since it gets in the way of the base options classes. We probably have to use a wrapper like @pinpointTownes suggested that's only used in the UseXyz overloads (alternative implementation of IOptions basically)

I think UseXyz() should exist where appropriate, its definitely not always appropriate for middleware that requires configuration keys etc

[kevinchalet]

Should we also have the empty overload of UseXyz() to pull options from DI without touching them?

@divega that's more or less the pattern I recently suggested to @HaoK (except that my approach was still compatible with named options): https://github.com/PinpointTownes/Security/commit/26b511f3d294f4b9545e1fbc57e4ef5226672118#commitcomment-12263892

We probably have to use a wrapper like @pinpointTownes suggested that's only used in the UseXyz overloads (alternative implementation of IOptions basically)

Ideally, you could even use it everywhere you have to deal with IOptions<TOptions> (like MemoryCache, whose constructor requires IOptions<MemoryCacheOptions>):

public static MemoryCache Create(MemoryCacheOptions options) {
    return new MemoryCache(new Options<MemoryCacheOptions>(options));
}

var cache = MemoryCache.Create(new MemoryCacheOptions {
    CompactOnMemoryPressure = false
});

[HaoK]

If we go the wrapper route, we should probably just enhance the existing OptionsManager implementation of IOptions to support this usage rather than a different duplicate class with a very similar name and purpose

[divega]

Interesting. I also suggested a wrapper when we met. My variation had a static method that would wrap any T instance into an IOptions<T>. Think Options.Create(new XyzOptions { Whatever = x }). The main push back was discoverability.

[divega]

BTW, if the base class is just for convenience it would be OK for options that need their own base classes to implement IOptions<T> on their own, correct? I.e. it should be OK to have the base class and just not use it always.

[HaoK]

Yes this is what I ended up doing for the security auth options

[HaoK]

Looks like we've settled on not using IOptions for middleware options in general