Support IFunctionsHostBuilder initialization

[SashaPshenychniy]

Microsoft updated a way to register startup actions for Azure Functions v2. Now instead of IWebJobsBuilder we should use IFunctionsHostBuilder, so extension methods from this library cannot be used anymore with latest version of Azure Functions.

Code would not change at all, just new type to apply extension method to should be added.

[StefH]

The main question is: do we still need this project because DI is now supported natively.

[SashaPshenychniy]

@StefH As far as I see only constructor injection is supported natively. This project extends it with parameter-injection which is very handy in many cases.

[StefH]

That's correct. However the question is why parameter-injection is useful?

If the methods (functions) all need different dependencies, then maybe just create new class for each function.

[SashaPshenychniy]

That's more of a philosophical question. Definitely it is possible to live with just constructor injection. But on the other hand, dependency injection containers in theory should not make limitations on how to write the code as long as DI principles are followed. Books on DI clearly define method injection as one of the ways to inject dependencies, so it looks as shortcoming from Microsoft not to support it.

As for scenario I would use method injection for is a set of functions, operating with some entity (e.g. Customer). Such class could take IDbConnection as constructor-injected dependency. But each method may need additional settings (e.g. SQL command timeout, or batch size) which would look weird if all are combined into single object, injected as constructor argument - much more natural to receive required parameters into corresponding methods.
There may be other scenarios of course (e.g. take complex dependency just for one specific method such as delete customer may need to notify some external system via queue message), but I really think scenarios isn't the key here - it's the principle of not limiting coding possibilities with framework we choose, so I still find your library particularly useful. Moreover it shouldn't take more than few minutes to allow using it with IFunctionsHostBuilder.

[joaoantunes]

Yes, it makes sense because the .Net DI features are very basic.
This is copied from Microsoft documentation:

"The built-in service container is meant to serve the needs of the framework and most consumer apps. We recommend using the built-in container unless you need a specific feature that it doesn't support. Some of the features supported in 3rd party containers not found in the built-in container:

• Property injection
• Injection based on name
• Child containers
• Custom lifetime management
• Func support for lazy initialization

"