aspnet/Hosting

Overloading Configure

sliekens opened this issue · 8 comments

I was told by @Tratcher to create a new issue from #301

Currently you are not allowed to have multiple Configure methods in a startup class.

InvalidOperationException: Having multiple overloads of method 'Configure' is not supported.

Is this an artificial limitation? Why not just invoke every overload?

We don’t do runtime overload resolution. It’s extremely complicated. Why do you need overloads? What are you trying to do?

I have a bunch of singleton services that need to be configured during startup.

ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IService1, MyService1>();
    services.AddSingleton<IService2, MyService2>();
    // etc
}

Configure(IApplicationBuilder app, IHostingEnvironment env, IService2 service1, IService2 service2)
{
    service1.ConfigureStuff(env);
    service2.ConfigureMoreStuff(env);
    // etc
}

Just pretend there's no way for me to do the configuring stuff inside a DI factory function or in the constructor and still be able to sleep at night.

My point is that you have to all your configuration in one Confgure method. My question is about why we can't split it up into overloads.

Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // middleware config
}

Configure(IService1 service1, IHostingEnvironment env)
{
    service1.ConfigureStuff(env);
}

Configure(IService2 service2, IHostingEnvironment env)
{
    service2.ConfigureMoreStuff(env);
}

The framework would then call each overload in whatever order, and I get to keep my sanity.

Sorry, we're not going to support that. It's extremely complex to get it right and there are ways to work around it.

Okay then just out of curiosity, what makes this hard to do? What's the difference between calling 1 Configure method or N+1 Configure methods?

For starters, ordering can matter. And then what about configure methods in sub classes and base classes? There are a lot of loose ends you'd have to chase.

@jaredpar can give you horror stories about implementing overload resolution in the compiler itself.

And then what about configure methods in sub classes and base classes?

Don't you already have this problem with just one Configure method? Does that throw on purpose too? I would be totally okay with throwing by design for weird inheritance trees in startup code.

Closed because you can actually just rely on the compiler to resolve overloads.

Configure(IApplicationBuilder app, IHostingEnvironment env, IService2 service1, IService2 service2)
{
    ConfigureImpl(app, env);
    ConfigureImpl(service1, env);
    ConfigureImpl(service2, env);
}

ConfigureImpl(IApplicationBuilder app, IHostingEnvironment env)
{
    // middleware config
}

ConfigureImpl(IService1 service1, IHostingEnvironment env)
{
    service1.ConfigureStuff(env);
}

ConfigureImpl(IService2 service2, IHostingEnvironment env)
{
    service2.ConfigureMoreStuff(env);
}

This is nice enough for me.