Azure Functions v2 Breaking Change for custom bindings

These days, The breaking change has been announced. For the v2 users, Don’t worry. Just follow this announcement.
However, your CustomBindings will be broken. I’d like to share some simple step how to migrate your current Custom Bindings to adopt the new model.
Now I share the basic step, however after trying experiment, I’ll edit this post.
Overview
New Bindings model are introduced the DI model. You can configure your bindings with DI feature. It is fantastic!
I start with simply migrate from your current custom bindings. I personally use this guy’s cool DI bindings.
Migration
Extension attribute
Add an Extension attribute on your implementation of the IExtensionConfigProvider . Like this.
using Microsoft.Azure.WebJobs.Description;
:[Extension("Inject")]public class InjectConfigurationProvider : IExtensionConfigProvider
Add ExtensionMethod for IWebJobsBilder
Then add extension method to IWebJobsBuilder to register your IExtensionConfigProvider implementation.
Add WebJobsStartup class
This class add your extension to the builder. Azure Functions Host find this startup class and execute Configure.
Usually migration might be finished. Usually That’s it.
Additional change
In this case, I have one more error. Some API seems to change. This DI bindings get IExtensionRegistry from Config. However, there is no config anymore on the context object.
This change might be handled by the new DI system. :) However, I don’t know the IFunctionInvocationFilter . So I did very bad practice using black magic. After investigating new DI system, I’ll write the solution.
:
var registry = context.GetExtensionRegistry();
:public static class ExtensionConfigContextExtensions
{
public static IExtensionRegistry GetExtensionRegistry(this ExtensionConfigContext context)
{
// private readonly IExtensionRegistry _extensionRegistry;var field = context.GetType().GetField("_extensionRegistry",
BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.Instance);return (IExtensionRegistry)field.GetValue(context);
}
Conclusion
The migration was not very tough, however, I didn’t have an information. I reference this commit.
SendGrid bindings also help to understand the change.
I keep on investigate the new DI feature of the bindings to improve my bindings. :)