As you know, IApplicationBuilder in the Configure method of a startup class in ASP.NET Core requires that the middleware class matches certain semantics (namely, to have the Invoke method that receives HttpContext and returns Task), but I do not understand why it was not done as an interface? After all, nothing prevents me from writing something like:

public class FakeMiddleware { }

then register it:

  app.UseMiddleware<FakeMiddleware>();

and IApplicationBuilder eats it as pretty (and how else, the UseMiddleware method does not indicate what to take) and get the error already in runtime. Of course, the problem is not worth a damn, and in case of an error it will be noticeable right away, just why did it be so ugly if there is a quite elegant solution with the interface?

    1 answer 1

    On the English-speaking stacker, I was already told that this is because the Invoke method may have additional parameters that will automatically be resolved by the built-in DI. What is logical. Only now the question arises that the interfaces in the form in which they are, do not cover the completely necessary functionality. Because the situation when there may be additional parameters, but which by default can be resolved and, therefore, optional for transmission, is far from being limited to the above described case with middleware.