WebApp.Start<TStartup> Method Type Parameter

Question

In setting up my Windows Service application to self host using Owin based on this article:

http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api

I used this overload of the WebApp.Start method:

WebApp.Start Method (String)

Here is my code:

//(in startup method) 
_server = WebApp.Start<Startup>(BaseAddress);

public class Startup
{
    // This code configures Web API. The Startup class is specified as a type
    // parameter in the WebApp.Start method.
    public void Configuration(IAppBuilder appBuilder)
    {
        // Configure Web API for self-host. 
        var config = new HttpConfiguration();
        config.Routes.MapHttpRoute("DefaultApi", "api/{controller}/{id}", new
        {
            id = RouteParameter.Optional
        });

        appBuilder.UseWebApi(config);
    }
} 

It works fine, so no complaints.

But what exactly are the requirements of the type parameter of the Start method? It doesn't appear to have any constraints, and I haven't been able to find any documentation on what my options/requirements are on this parameter. Does it look for methods that take IAppBuilder as a parameter? What if I change the name of the Configuration() method to something else? What if I make the method internal? Are there other options I can configure with this class?

Where is all of this this documented? I feel like without the article linked above, I never would have been able to figure out what to implement.

Answer 1

The WebApp class uses reflection to get a pointer to the Configuration(IAppBuilder) method then calls it. If the class you provide as the generic type argument does not have a Configuration method with the expected arguments then you get an error at run time.

I agree that this is not as discoverable as we would like and I am not sure why the original developers implemented it this way rather than adding a where T: IStartup constraint instead. Not only would this make it more discoverable without documentation, but would also have allowed the compiler to check this at compile time.

The only advantage to this approach is that the OWIN developers can add more methods or methods with different signatures in the future without breaking existing code.