Bootstrapper Loader for Layered Architecture

var scopeFactory = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>();
using (var scope = scopeFactory.CreateScope())
{
    _bootstrapperLoader.TriggerConfigure(scope.ServiceProvider.GetRequiredService);
}

One caveat is that: since we no longer reference Repository project from UI project, Visual Studio/msbuild will not copy Repository dll into bin folder of UI project for us automatically. So to work around this, I use PostBuild target in UI project BootstrapperLoaderDemo.csproj to copy those dlls automatically after build. However in order for this PostBuild target to work, we need to ensure BootstrapperLoaderDemo is built after its dependency (BootstrapperLoaderDemo.Repository) has finished building. At the moment I have to create a simple powershell/bash script to build projects individually to make sure that order is maintained. This is the biggest issue when adopting this library but it just needs to be setup once at the beginning 

<Target Name="PostPublish" AfterTargets="AfterPublish" >
  <ItemGroup>
    <ItemsToCopy Include="./../BootstrapperLoaderDemo.Repository/bin/$(Configuration)/$(TargetFramework)/publish/*" />
  </ItemGroup>
  <Copy SourceFiles="@(ItemsToCopy)" DestinationFolder="./bin/$(Configuration)/$(TargetFramework)/publish">
    <Output TaskParameter="CopiedFiles" ItemName="SuccessfullyCopiedFiles" />
  </Copy>
  <Message Importance="High" Text="PostPublish Target successfully copied:%0a@(ItemsToCopy->'- %(fullpath)', '%0a')%0a -&gt; %0a@(SuccessfullyCopiedFiles->'- %(fullpath)', '%0a')" />
</Target>

Loader Configuration

Default Configuration

By default, BootstrapperLoader has following settings:

• use FileSystemAssemblyProvider to look for all *.dll in current folder (Directory.GetCurrentDirectory())
• BootstrapperLoader.TriggerConfigure looks for Configure() method in any class with name Bootstrapper in dlls found above
• BootstrapperLoader.TriggerConfigureContainer looks for ConfigureContainer() method in any class with name Bootstrapper in dlls found above
• Bootstrapper class and Configure()/ConfigureContainer() can be either public or non-public

LoaderBuilder Configuration

The loader builder offers several configurations through Fluent API:

• WithName("SomeBootstrapper"): look for class with name SomeBootstrapper instead of Bootstrapper

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                      .ForClass()
                          .WithName("SomeBootstrapper")
                      .Build();
  </code>

• HasConstructorParameter<ISomeDependency>(): when creating Bootstrapper instance, use constructor that takes ISomeDependency parameter

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                      .ForClass()
                          .HasConstructorParameter<ISomeDependency>(new SomeDependency())
                      .Build();
  </code>

• When(condition).CallConfigure("SomeConfigure"): when calling BootstrapperLoader.TriggerConfigure(), if condition invocation is evaluated to true, call SomeConfigure() method in Bootstrapper classes in addition to Configure()

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                      .ForClass()
                          .When(env.IsDevelopment)
                              .CallConfigure("SomeConfigure")
                      .Build();
  </code>

• When(condition).CallConfigureContainer("SomeConfigureContainer"): when calling BootstrapperLoader.TriggerConfigureContainer(), if condition invocation is evaluated to true, call SomeConfigureContainer() method in Bootstrapper classes in addition to ConfigureContainer()

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                      .ForClass()
                          .When(env.IsDevelopment)
                              .CallConfigureContainer("SomeConfigureContainer")
                      .Build();
  </code>

• When(condition).AddMethodNameConvention("Development"): when calling BootstrapperLoader.TriggerConfigure()/ BootstrapperLoader.TriggerConfigureContainer(), if condition invocation is evaluated to true, call SomeConfigure()/SomeConfigureContainer() method in Bootstrapper classes in addition to Configure()/ConfigureContainer()

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                      .ForClass()
                          .When(env.IsDevelopment)
                              .AddMethodNameConvention("Development")
                      .Build();
  </code>

• Use(): specify an alternative assembly provider:

  Example:

  <code>_bootstrapperLoader = new LoaderBuilder()
                          .Use(new FileSystemAssemblyProvider(Directory.GetCurrentDirectory(), "MyCoolProject*.dll")) //Look into current directory, grabs all dlls starting with MyCoolProject
                          .Build();
  </code>

You can also create new Assembly Provider class, to customize the source of assemblies provided to the loader. At the moment, there are 2 classes provided: FileSystemAssemblyProvider and InMemoryAssemblyProvider

Trigger bootstrapper from root project

BootstrapperLoader provides 3 methods to trigger methods in sub-projects Bootstrapper class:

• TriggerConfigureContainer<TArg>(TArg parameter)

This method should be used when root project is doing IoC registration. Its parameter is usually IoC container or container builder. This method will look for ConfigureContainer method in Bootstrapper classes and pass in the parameter, allow Bootstrapper classes to register child projects' dependencies to IoC container

• TriggerConfigure(Func<Type, object> serviceLocator = null)

This method should be used when it's the right time to do any non-IoC configuration/initialization (.e.g. AutoMapper setting up). It can be called with or without serviceLocator parameter

This method takes Func<Type, object> as its parameter to allow Configure method in Bootstrapper classes to take in any number of dependencies (as long as those dependencies can be resolved using serviceLocator func). It works in the same way with Startup.Configure in ASP.NET Core

Func<Type, object> is used here to ensure this library is not dependent on any specific IoC container. Most IoC container should support a method with this signature (.e.g. in Autofac, it's Resolve() method)

When it's called without serviceLocator parameter, it will look for only Configure() method (without any parameter) in Bootstrapper classes

• Trigger<TArg>(string methodName, TArg parameter)

When this method is called, it will look for methods with specified name in Bootstrapper classes in sub-projects and invoke those, passing in provided parameter. This method is for any other situation where your project cannot use above 2 methods.

Library Design

Read this part only if you are interested in how I implemented the library

The main logic of the library is very simple and lies entirely in BootstrapperLoader class.

It relies on LoaderConfig to hold all necessary information to load and trigger bootstrapper classes (.e.g. bootstrapper class name, what methods to look for, etc)

During initialization, it looks for assemblies with Bootstrapper classes, creates instances of those bootstrapper classes and stores in a list.

When Trigger() method is called, it looks for method with specified name in stored list of boostrapper classes and invoke those:

public void Trigger<TArg>(string methodName, TArg parameter)
{
    Bootstrappers.ForEach(bootstrapper =>
        ExecuteIfNotNull(
            bootstrapper.GetType()
                .GetMethod(methodName, MethodBindingFlags, null, new[] {typeof(TArg)}, null),
            methodInfo => methodInfo.Invoke(bootstrapper, new object[] { parameter }))
    );
}

I need to write a custom method ExecuteIfNotNull() instead of using C# 6 safe navigation operator because I want to target my library to .NET 4.5.2 for wider target audience.

TriggerConfigureContainer() is similar. Config.ConfigureContainerMethods is a dictionary with key is the method name to look for and value is a Func<bool> to decide when to invoke that method

public void TriggerConfigureContainer<TArg>(TArg parameter)
{
    Bootstrappers.ForEach(bootstrapper =>
    {
        Config.ConfigureContainerMethods
            .Where(c => c.Value())
            .ToList()
            .ForEach(methodConfiguration => 
                ExecuteIfNotNull(
                    bootstrapper.GetType().GetMethod(methodConfiguration.Key, MethodBindingFlags, null, new[] {typeof(TArg)}, null),
                    methodInfo => methodInfo.Invoke(bootstrapper, new object[] { parameter }))
            );
    });
}

Things are a bit more interesting when TriggerConfigure() is called:

public void TriggerConfigure(Func<Type, object> serviceLocator = null)
{
    Bootstrappers.ForEach(bootstrapper =>
    {
        Config.ConfigureMethods
               .Where(c => c.Value())
               .ToList()
               .ForEach(methodConfiguration => 
                        ExecuteIfNotNull(
                            GetMethodInfoByName(bootstrapper.GetType(), methodConfiguration.Key, serviceLocator),
                            methodInfo => methodInfo.InvokeWithDynamicallyResolvedParameters(bootstrapper, serviceLocator))
                       );
    });
}

First, it needs to evaluate condition for Configure() conditional call and only selects methods that condition evaluates to true. Second, I have an extension method  InvokeWithDynamicallyResolvedParameters() for invoking these methods:

public static void InvokeWithDynamicallyResolvedParameters(this MethodInfo configureMethod, object bootstrapper, Func<Type, object> serviceLocator)
{
    var parameterInfos = configureMethod.GetParameters();
    var parameters = new object[parameterInfos.Length];
    for (var index = 0; index < parameterInfos.Length; index++)
    {
        var parameterInfo = parameterInfos[index];

        try
        {
            parameters[index] = serviceLocator(parameterInfo.ParameterType);
        }
        catch (Exception ex)
        {
            //Omitted for brevity
        }
    }

    configureMethod.Invoke(bootstrapper, parameters);
}

What this method does is just to iterate through the list of parameters for Bootstrapper Configure() method and tries to resolve those parameters using provided serviceLocator. If you take a look at ASP.NET Core source code, you will find this almost exactly the same as the logic ASP.NET Core used to trigger Startup.Configure(). I would not be able to figure out how to do this initially, so I had to take a look at ASP.NET Core implementation and “borrowed” the idea.

The remaining classes in the library are used to provide Fluent API configuration for loader builder. The only purpose of loader builder is to let client specify different options for LoaderConfig and passes it to BootstrapperLoader in the end.