Register Azure Functions binding extensions

Starting with Azure Functions version 2.x, the functions runtime only includes HTTP and timer triggers by default. Other triggers and bindings are available as separate packages.

.NET class library functions apps use bindings that are installed in the project as NuGet packages. Extension bundles allow non-.NET functions apps to use the same bindings without having to deal with the .NET infrastructure.

The following table indicates when and how you register bindings.

Development environment Registration
in Functions 1.x
Registration
in Functions 2.x or later
Azure portal Automatic Automatic*
Non-.NET languages Automatic Use extension bundles (recommended) or explicitly install extensions
C# class library using Visual Studio Use NuGet tools Use NuGet tools
C# class library using Visual Studio Code N/A Use .NET Core CLI

* Portal uses extension bundles, including C# script.

Extension bundles

By default, extension bundles are used by Java, JavaScript, PowerShell, Python, C# script, and Custom Handler function apps to work with binding extensions. In cases where extension bundles can't be used, you can explicitly install binding extensions with your function app project. Extension bundles are supported for version 2.x and later version of the Functions runtime.

Extension bundles are a way to add a pre-defined set of compatible binding extensions to your function app. Extension bundles are versioned. Each version contains a specific set of binding extensions that are verified to work together. Select a bundle version based on the extensions that you need in your app.

When you create a non-.NET Functions project from tooling or in the portal, extension bundles are already enabled in the app's host.json file.

An extension bundle reference is defined by the extensionBundle section in a host.json as follows:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[4.0.0, 5.0.0)"
    }
}

The following properties are available in extensionBundle:

Property Description
id The namespace for Microsoft Azure Functions extension bundles.
version The version range of the bundle to install. The Functions runtime always picks the maximum permissible version defined by the version range or interval. For example, a version value range of [4.0.0, 5.0.0) allows all bundle versions from 4.0.0 up to but not including 5.0.0. For more information, see the interval notation for specifying version ranges.

The following table lists the currently available version ranges of the default Microsoft.Azure.Functions.ExtensionBundle bundles and links to the extensions they include.

Bundle version Version in host.json Included extensions
1.x [1.*, 2.0.0) See extensions.json used to generate the bundle.
2.x [2.*, 3.0.0) See extensions.json used to generate the bundle.
3.x [3.3.0, 4.0.0) See extensions.json used to generate the bundle.
4.x [4.0.0, 5.0.0) See extensions.json used to generate the bundle.

Note

Even though host.json supports custom ranges for version, you should use a version range value from this table, such as [4.0.0, 5.0.0).

Explicitly install extensions

For compiled C# class library projects (in-process and isolated worker process), you install the NuGet packages for the extensions that you need as you normally would. For examples see either the Visual Studio Code developer guide or the Visual Studio developer guide.

For non-.NET languages and C# script, when you can't use extension bundles you need to manually install required binding extensions in your local project. The easiest way is to use Azure Functions Core Tools. For more information, see func extensions install.

For portal-only development, you need to manually create an extensions.csproj file in the root of your function app. To learn more, see Manually install extensions.

Next steps