Azure-webjobs-sdk: Proper DI support for JobHostConfiguration

[MikeStall]

Provide a proper Dependency Injection story for JobHostConfiguration.

Currently, the JobHostConfiguration initialization is pretty adhoc and ends up being an 8-step process described here: https://github.com/Azure/azure-webjobs-sdk/wiki/Initialization

We need to provide a consistent natural DI story. Some requirements:

1. Good support for scenarios handled by Logging, TypeLocators, IJobActivator, INameResolver
2. Possibly completely remove IJobActivator and just get the types directly from the service provider.
3. Extensions should not need to call JobHostConfiguration.GetService. Instead, extensions should get registered and created by the DI system and have their services injected.
4. Extensions definitely shouldn't be injecting services via calls to SetService<>
5. Avoid bugs we have no around startup ordering.
6. Allow default implementations that can also be overridden.
7. Support getting the IMetadataProvider service, which can only be created after all extensions are registered.
8. JobHostConfiguration should become immutable.

Consider leveraging new DI interfaces from .NET core. We should avoid taking a dependency on a specific DI implementation. ASP.Net does a good job of this.

[xt0rted]

I've used StructureMap and TinyIoC in the past. Currently I've skipped the DI and just new up my dependencies at the top of the functions because it was easier than setting up the DI. Definitely looking forward to seeing some changes to this.

[fabiocav]

@xt0rted we'll be sharing some additional thoughts we have around this so we can iterate and get some feedback, but the goal is to be flexible enough so you could also plug your own DI framework and address the DI pains we've been hearing about for so long. :)

[mathewc]

Related to https://github.com/Azure/azure-webjobs-sdk/issues/1036

[christopheranderson]

@MikeStall - Could we add these details to #1036 and close this?

[Bio2hazard]

I've come up with a pretty easy way to get CTOR DI working for functions. Sharing it here so that others can implement it and so that the team is aware of how CTOR DI is currently achieved:

The DI Framework I use is SimpleInjector ( http://simpleinjector.readthedocs.io/en/latest/ ).

Here is a gist with code samples:
https://gist.github.com/Bio2hazard/3817ba5f291176f465baa263350925f5

A summary of what is happening:
Program.cs' Main: Initialize DI Container and pass it into a custom JobActivator
Custom JobActivator: Request class from container, check class for inheriting specific base class and register container to instantiated class.
FunctionBase: Accept container scope, implement IDisposable, dispose scope when disposed.

[justinyoo]

At this moment, managing dependencies in Azure Functions can be done in an interesting way. I've written a blog post for this:

https://devkimchi.com/2017/11/16/azure-functions-with-ioc-container/

However, IJobActivator can be something we can make use of DI for Azure Functions. Whenever I write an Azure WebJob instance, I usually use IJobActivator for DI together with Autofac like:

https://blog.kloud.com.au/2017/09/06/make-your-azure-webjobs-unit-testable-again/

Here are my NuGet packages for this:

• https://www.nuget.org/packages/WebJobActivator.Autofac/
• https://www.nuget.org/packages/WebJobActivator.Core/

If we can implement the IJobActivator, declare it on host.json or somewhere else, and Azure Functions runtime can detect it, it would probably be very handy for managing dependencies.

[fabiocav]

This issue is being decomposed into the following items (some of which will be further decomposed to track more concrete tasks):

• #1559
• #1560
• #1561
• #1562