Website Startup

When using Cofoundry in an asp.net web application, Cofoundry needs to manage the application startup process so that it can make sure everything is registered in the correct order and allow plugins to self-register.

Startup uses Owin and requires you to initialize your application using an Owin Startup class, first registering a DI integration package and then running app.UseCofoundry() to include Cofoundry in the pipeline.

Example Startup.cs

using Microsoft.Owin;
using Owin;
using Cofoundry.Plugins.DependencyInjection.AutoFac.Web;
using Cofoundry.Web;

[assembly: OwinStartup(typeof(MySite.Startup))]

namespace MySite 
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // A DI integration package must be run before the main Cofoundry registration.
            // To add your own dependency registrations, you can implement an IDependencyRegistration
            // or use the overload to provide additional configuration
            app.UseCofoundryAutoFacIntegration();
    
            // Register Cofoundry into the pipeline. As part of this process it also initializes 
            // MVC/WebApi and runs additional startup tasks.
            app.UseCofoundry();
        }
    } 
}

What happens at startup?

The startup process is modularized into a set of tasks that all implement IStartupTask, which makes it really easy to inject your own startup tasks into the process (the Startup Tasks docs has more info about creating your own).

Here's a list of everything Cofoundry does at startup.

• AutoUpdateMiddlewareRegistrationStartupTask Initializes the Auto Update process
• ViewEngineInitializationStartupTask Initializes the custom view engine required to pull in embedded resources from Cofoundry modules.
• JsonConverterConfigurationStartupTask Configures the default JsonSerialization settings using IJsonSerializerSettingsFactory
• MvcConfigurationStartupTask Initializes Asp.Net MVC with a couple of Cofoundry settings
• WebApiConfigurationStartupTask Configures Asp.Net WebApi and runs config.EnsureInitialized(). If you need to add your own web api configuration it's best to override and wrap the IWebApiStartupConfiguration implementation.
• MvcFilterConfigurationStartupTask Registers a few Cofoundry MVC filters
• MvcRouteConfigurationStartupTask Registers Cofoundry content routes, initializes embedded resource routing and registers and routes configured in IRouteRegistration classes.
• AutoMapperConfigurationStartupTask Bootstraps AutoMapper, registering Profile classes
• BundlingInitializationStartupTask Initializes Asp.Net Bundling, registering IBundleRegistration classes
• MessageSubscriptionInitializerStartupTask Bootstraps the Message Aggregator, registering IMessageSubscriptionRegistration classes

Note that plugins may also inject their own startup tasks in this process.

Customizing the Startup Process

Many startup tasks include their own insertion points that allow you to include your own registrations e.g. IRouteRegistration or IBundleRegistration (see the documentation area for each of thsse as to how these systems work).

Additionally each startup task tends to use an injectable initializer that can be overridden using the Dependency Injection system.

As a last resort we also provide a configuration option that lets you filter the startup task collection in any way you choose:

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseCofoundryAutoFacIntegration();
        app.UseCofoundry(config => config.FilterStartupTasks(MyStartupTaskFilter));
    }

    private IEnumerable<IStartupTask> MyStartupTaskFilter(IEnumerable<IStartupTask> startupTasks)
    {
        // E.g. maybe we wanted to remove the JsonConverter config task for some reason
        return startupTasks.Where(t => !(t is JsonConverterConfigurationStartupTask));
    }
}

Feedback

This is an area that may change when we move to Asp.Net Core and we're also interested in feedback as to whether this is the best way to bootstrap your application, whether it gives you enough flexibility and whether the api feels right. See Issue 47 to add feedback