The build process creates a function.json file for each function. This function.json file is not meant to be edited directly. You can't change binding configuration or disable the function by editing this file. To learn how to disable a function, see How to disable functions.

Methods recognized as functions

In a class library, a function is a static method with a FunctionName and a trigger attribute, as shown in the following example:

The FunctionName attribute marks the method as a function entry point. The name must be unique within a project, start with a letter and only contain letters, numbers, _, and -, up to 127 characters in length. Project templates often create a method named Run, but the method name can be any valid C# method name.

The trigger attribute specifies the trigger type and binds input data to a method parameter. The example function is triggered by a queue message, and the queue message is passed to the method in the myQueueItem parameter.

Method signature parameters

The method signature may contain parameters other than the one used with the trigger attribute. Here are some of the additional parameters that you can include:

The order of parameters in the function signature does not matter. For example, you can put trigger parameters before or after other bindings, and you can put the logger parameter before or after trigger or binding parameters.

Output binding example

The following example modifies the preceding one by adding an output queue binding. The function writes the queue message that triggers the function to a new queue message in a different queue.

Autogenerated function.json

The build process creates a function.json file in a function folder in the build folder. As noted earlier, this file is not meant to be edited directly. You can't change binding configuration or disable the function by editing this file.

The purpose of this file is to provide information to the scale controller to use for scaling decisions on the consumption plan. For this reason, the file only has trigger info, not input or output bindings.

The generated function.json file includes a configurationSource property that tells the runtime to use .NET attributes for bindings, rather than function.json configuration. Here's an example:

Microsoft.NET.Sdk.Functions

The same package is used for both version 1.x and 2.x of the Functions runtime. The target framework is what differentiates a 1.x project from a 2.x project. Here are the relevant parts of .csproj files, showing different target frameworks and the same Sdk package:

Among the Sdk package dependencies are triggers and bindings. A 1.x project refers to 1.x triggers and bindings because those triggers and bindings target the .NET Framework, while 2.x triggers and bindings target .NET Core.

The Sdk package also depends on Newtonsoft.Json, and indirectly on WindowsAzure.Storage. These dependencies make sure that your project uses the versions of those packages that work with the Functions runtime version that the project targets. For example, Newtonsoft.Json has version 11 for .NET Framework 4.6.1, but the Functions runtime that targets .NET Framework 4.6.1 is only compatible with Newtonsoft.Json 9.0.1. So your function code in that project also has to use Newtonsoft.Json 9.0.1.

Runtime version

Visual Studio uses the Azure Functions Core Tools to run Functions projects. The Core Tools is a command-line interface for the Functions runtime.

If you install the Core Tools by using npm, that doesn't affect the Core Tools version used by Visual Studio. For the Functions runtime version 1.x, Visual Studio stores Core Tools versions in %USERPROFILE%\AppData\Local\Azure.Functions.Cli and uses the latest version stored there. For Functions 2.x, the Core Tools are included in the Azure Functions and Web Jobs Tools extension. For both 1.x and 2.x, you can see what version is being used in the console output when you run a Functions project:

Binding to method return value

You can use a method return value for an output binding, by applying the attribute to the method return value. For examples, see Triggers and bindings.

Use the return value only if a successful function execution always results in a return value to pass to the output binding. Otherwise, use ICollector or IAsyncCollector, as shown in the following section.

Writing multiple output values

To write multiple values to an output binding, or if a successful function invocation might not result in anything to pass to the output binding, use the ICollector or IAsyncCollector types. These types are write-only collections that are written to the output binding when the method completes.

This example writes multiple queue messages into the same queue using ICollector:

Cancellation tokens

A function can accept a CancellationToken parameter, which enables the operating system to notify your code when the function is about to be terminated. You can use this notification to make sure the function doesn't terminate unexpectedly in a way that leaves data in an inconsistent state.

The following example shows how to check for impending function termination.

App settings can be read from environment variables both when developing locally and when running in Azure. When developing locally, app settings come from the Values collection in the local.settings.json file. In both environments, local and Azure, GetEnvironmentVariable("<app setting name>") retrieves the value of the named app setting. For instance, when you're running locally, "My Site Name" would be returned if your local.settings.json file contains { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

Binding at runtime

In C# and other .NET languages, you can use an imperative binding pattern, as opposed to the declarative bindings in attributes. Imperative binding is useful when binding parameters need to be computed at runtime rather than design time. With this pattern, you can bind to supported input and output bindings on-the-fly in your function code.

Define an imperative binding as follows:

Do not include an attribute in the function signature for your desired imperative bindings.

BindingTypeAttribute is the .NET attribute that defines your binding, and T is an input or output type that's supported by that binding type. T cannot be an out parameter type (such as out JObject). For example, the Mobile Apps table output binding supports six output types, but you can only use ICollector or IAsyncCollector with imperative binding.

Single attribute example

The following example code creates a Storage blob output binding
with blob path that's defined at run time, then writes a string to the blob.

Multiple attribute example

The preceding example gets the app setting for the function app's main Storage account connection string (which is AzureWebJobsStorage). You can specify a custom app setting to use for the Storage account by adding the
StorageAccountAttribute
and passing the attribute array into BindAsync<T>(). Use a Binder parameter, not IBinder. For example: