Server Options not flowing with Autofac

[douglaswaights]

Hi,

When using WebListener in conjunction with Autofac DI container in RC2 the claims principle name always come back null.

Removing the IServiceProvider ConfigureServices(...) method and the identity name is available again...

Is this a bug or am I doing something wrong?

I've created a sample showing the issue
https://github.com/douglaswaights/weblistenerDI

Thanks
Doug

[Tratcher]

I wonder if the UseWebListener Options object is somehow being dropped when switching to the new DI container, so the server gets started with the default options. If that's true, you should have similar issues configuring Kestrel.

[Tratcher]

I was able to reproduce this with both Kestrel and WebListener. They both use the same WebHostBuilder extension pattern:
https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNetCore.Server.Kestrel/WebHostBuilderKestrelExtensions.cs

They register a transient IConfigureOptions<KestrelServerOptions> and a singleton services.Configure(options);. Only the transient registration appears to make it across into the Autofac container, so any developer configured options from Main get lost. In Kestrel it's even slightly worse were KestrelServer null refs on the options in its constructor.

Not sure if Autofac needs to be smarter or if Kestrel and WebListener need to register their options differently.

[Tratcher]

@halter73 No luck making both services into singletons. Can you take a look? The repro is easy:
https://github.com/douglaswaights/weblistenerDI/blob/master/src/weblistener/Startup.cs#L14-L22

[halter73]

The root problem seems to be that Options relies on ordering: https://github.com/aspnet/Options/blob/c7bff7184d3a3ab4074859b3fd3d36d83c474357/test/Microsoft.Extensions.Options.Test/OptionsTest.cs#L143

Autofac doesn't support that. I can't find a more authoritative source atm.

Turns out that the following is also broken along with more things that rely on options I'm sure.

new WebHostBuilder()
    .UseKestrel(options =>
    {
        options.UseHttps("testCert.pfx", "testPassword");

[davidfowl]

@HaoK did we ever test this when we removed the order parameter from options? This is a pretty big break.

/cc @muratg @Eilon

[HaoK]

Ugh, at the time MVC was the only one that was using the ordering overloads, and they were okay with removing that behavior. But yes options relies on IEnumerable of the IConfigureOptions ordering which if is random means its will be impossible to tell what the expected option values will be...

[douglaswaights]

Is this fixable for RTM do you think? Without ripping out autofac across our app its kinda blocking our upgrade from RC1.

Cheers

[muratg]

@davidfowl @HaoK @halter73 What's a simple change we can do to fix this in RTM?

cc @Eilon

[HaoK]

I'm not sure there is a simple fix. There used to be overloads that specified an int for order for options to be sorted by but those were removed a long time ago.

[HaoK]

Would we be able to workaround this by removing the default IConfigureOption setups for kestrel/weblistener? Each only appears to be stuffing either a logger factory or the application services into its options. Can't you take those as service dependencies in the server themselves instead of hanging them off the options? Then there would only be one configure options and less of an ordering issue. That would paper things over at least...

[Tratcher]

@pakrym is trying to refactor the Kestrel scenarios. I'll try to refactor the WebListener ones.