IStartup vs IHostingStartup

IStartup vs IHostingStartup

Jun 18, 2017     Viewed 3131 times 0 Comments
Posted in #IStartup  #IHostingStartup  #Hosting 

IStartup Interface

Everyone who work with ASP.NET Core familiar with Startup class that responsible for bootstrapping the services needed by your application, as well as setting up the application pipeline. This class basically used a convention based pattern, but you can use the interface IStartup if you do so.

This allows you to use the conventions too if you are running in multiple environments, for more information you can have a look to one of my old blog posts Convention-Based Application Startup in Multiple Environments.

The IStartup interface is very useful in many cases, especially if you need to resolve the Startup class from the DI container for whatever the reason. There's a very good blog post from Flip W. who wrote a post about Resolving ASP.NET Core Startup class from the DI container.

IHostingStartup Interface

The thing that some of the ASP.NET Core developers doesn't know about is IHostingStartup that represents platform specific configuration that will be applied to a IWebHostBuilder when building an IWebHost.

To give you a real world example of IHostingStartup, let us look to the following:

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseStartup()
        .UseApplicationInsights()
        .Build();

    host.Run();
}

which the Program.cs code that we usually wrote, if you look closely to UseApplicationInsights() extension method, you will notice that the previous version of ASP.NET Core applications have a dependency to Microsoft Application Insights, but this is changed in ASP.NET Core 2.0 Preview basically you don't have to do anything, the application does not have a dependency on Application Insights anymore, but still you have the usual application insights telemetry in Visual Studio.

How this work? if we look closely to the ApplicationInsightsHostingStartup code

public class ApplicationInsightsHostingStartup : IHostingStartup
{
    private const string ApplicationInsightsSettingsFile = "ApplicationInsights.settings.json";

    public void Configure(IWebHostBuilder builder)
    {
        builder.UseApplicationInsights();
        builder.ConfigureServices(InitializeServices);
    }
    ...
}

it implements the IHostingStartup interface, which is lightup the application insights experience dynamically with the help of the HostingStartup attribute.

[assembly: HostingStartup(typeof(Microsoft.AspNetCore.ApplicationInsights.HostingStartup.ApplicationInsightsHostingStartup))]

With this you can inject a DLL into an ASP.NET Core application without the application knows anything about the injected DLL, nothing but we need to setup some environment variables, to let the runtime load the dependency.

ASPNETCORE_HOSTINGSTARTUPASSEMBLIES={Assembly.HostingStartupClass}

the first environment variable will point to the assembly that has the class which implements IHostingStartup interface

DOTNET_ADDITIONAL_DEPS={AssemblyPath}\additionaldeps

the second environment variable will tell the runtime to take a look in there to see if there are any dependency files that might match and merge them into our applications dependency tree.


Leave a Comment