Aspnetcore: Question: Why does the 'Startup' class not have to implement some basic interface?

[Korporal]

I'm rather curious about what I see in a new ASP.NET Core Web App project when I create one from the VS 2017 template.

The program class (akin to a Console app) passes the type Startupwhen it invokes the generic UseStartup<T>()method.

In Startup.cs I see methods ConfigureServicesand Configure- both of which are called by "the runtime".

This strikes me as a perfect and pretty obvious example of where an interface would be used, Yet the generic UseStartupmethod has a contraint that is nothing more than where TStartup : class.

If I create a deliberately dumb class I get no compile time messages, just this runtime message:

InvalidOperationException: A public method named 'ConfigureDevelopment' or 'Configure' could not be found in the 'CoreWeb1.DumbStartup' type.

So what's the reasoning behind this when the C# language provides a host of capabilities? Surely this isn't something you'd address through a pull request, for example by altering this file?

[Tratcher]

Because then we couldn't do magic like this:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-2.1#environment-based-startup-class-and-methods

[davidfowl]

Previous discussions on the topic https://github.com/aspnet/Hosting/issues/1311

[Korporal]

@Tratcher - I see no reason why an attribute is not sufficient for this [Environment("Development")]for example would annotate some startup class (which could then easily implement an interface) and be the class which is used. Frankly I consider this poor design when the C# language provides easily enough features to achieve what's required without relying on class/method naming conventions, it just seems like it sets a bad example to novice developers and if used as a general pattern would surely lead to all kinds of maintenance challenges.

[oliverjanik]

Fully agree. Stop the magic for 80% of common use cases.

Keep your reflection based nonsense for people who like when their production systems blow up in run-time.

[davidfowl]

I’m closing this issue. I linked to a similar issue somebody else filed like this in the past and rather than leave this issue open, I’m closing it becuse we have no plans to make any breaking changes here. We also already have an interface and it doesn’t work in all cases (described in the other issue).

If you have a more concrete complaint with a practical solution we can look at improving things in future releases.

[oliverjanik]

Thanks for acknowledging it's a bad design. 👍

Your interfaces are still a hack. There's still reflection and run-time arg passing.

[athinboy]

I think @oliverjanik is right!
I think UseMiddlewareExtensions.UseMiddleware is a bad design! Very Bad!