This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Important

Support will end for the in-process model on November 10, 2026 . We highly recommend that you migrate your apps to the isolated worker model for full support.

Functions execute in the same process as the Functions host. To learn more, see Develop C# class library functions using Azure Functions .

In a variation of this model, Functions can be run using C# scripting , which is supported primarily for C# portal editing. To update existing binding extensions for C# script apps running in the portal without having to republish your function app, see Update your extensions .

The functionality of the extension varies depending on the extension version:

This section describes using a class library . For C# scripting , you would need to instead install the extension bundle , version 4.x.

This version introduces the ability to connect using an identity instead of a secret . For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial .

This version allows you to bind to types from Azure.Storage.Queues .

This extension is available by installing the Microsoft.Azure.WebJobs.Extensions.Storage.Queues NuGet package , version 5.x.

Using the .NET CLI:

dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage.Queues
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET in-process app, you should add the following packages to your project:
Microsoft.Azure.WebJobs.Extensions.Storage.Blobs
Microsoft.Azure.WebJobs.Extensions.Storage.Queues
Microsoft.Azure.WebJobs.Extensions.Tables
Previously, the extensions shipped together as Microsoft.Azure.WebJobs.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.WebJobs.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
This section describes using a class library. For C# scripting, you would need to instead install the extension bundle, version 2.x.
Working with the trigger and bindings requires that you reference the appropriate NuGet package. Install the NuGet package, version 3.x or 4.x.
Important
Support will end for version 1.x of the Azure Functions runtime on September 14, 2026. We highly recommend that you migrate your apps to version 4.x for full support.
Functions 1.x apps automatically have a reference the Microsoft.Azure.WebJobs NuGet package, version 2.x.
In Functions 1.x, the Storage triggers and bindings use version 7.2.1 of the Azure Storage SDK (WindowsAzure.Storage NuGet package). If you reference a different version of the Storage SDK, and you bind to a Storage SDK type in your function signature, the Functions runtime may report that it can't bind to that type. The solution is to make sure your project references WindowsAzure.Storage 7.2.1.

This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
This version allows you to bind to types from Azure.Storage.Queues.
Add the extension to your project by installing the NuGet package, version 5.x.
Using the .NET CLI:
dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues --version 5.0.0
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET isolated-process app, you should add the following packages to your project:
Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
Microsoft.Azure.Functions.Worker.Extensions.Tables
Previously, the extensions shipped together as Microsoft.Azure.Functions.Worker.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.Functions.Worker.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
You can add this version of the extension from the preview extension bundle v3 by adding or replacing the following code in your host.json file:
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
To learn more, see Update your extensions.
You can install this version of the extension in your function app by registering the extension bundle, version 2.x.
Functions 1.x apps automatically have a reference to the extension.
Queue output (single message)
QueueMessage
JSON serializable types1
string
byte[]
BinaryData
Queue output (multiple messages)
QueueClient
ICollector<T> or IAsyncCollector<T> where T is one of the single message types
1 Messages containing JSON data can be deserialized into known plain-old CLR object (POCO) types.
Earlier versions of the extension exposed types from the now deprecated Microsoft.Azure.Storage.Queues namespace. Newer types from Azure.Storage.Queues are exclusive to Extension 5.x+.
This version of the extension supports parameter types according to the table below.
Binding scenario
Parameter types
The isolated worker process supports parameter types according to the tables below. Support for binding to types from Azure.Storage.Queues is in preview.
Queue trigger
The queue trigger can bind to the following types:
Description
JSON serializable types
When a queue message contains JSON data, Functions tries to deserialize the JSON data into a plain-old CLR object (POCO) type.
QueueMessage1
The message.
BinaryData1
The bytes of the message.
1 To use these types, you need to reference Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues 5.2.0 or later and the common dependencies for SDK type bindings.
Queue output binding
When you want the function to write a single message, the queue output binding can bind to the following types:
Description
host.json settings
This section describes the configuration settings available for this binding in versions 2.x and higher. Settings in the host.json file apply to all functions in a function app instance. The example host.json file below contains only the version 2.x+ settings for this binding. For more information about function app configuration settings in versions 2.x and later versions, see host.json reference for Azure Functions.
For a reference of host.json in Functions 1.x, see host.json reference for Azure Functions 1.x.
    "version": "2.0",
    "extensions": {
        "queues": {
            "maxPollingInterval": "00:00:02",
            "visibilityTimeout" : "00:00:30",
            "batchSize": 16,
            "maxDequeueCount": 5,
            "newBatchThreshold": 8,
            "messageEncoding": "base64"
maxPollingInterval
00:01:00
The maximum interval between queue polls. The minimum interval is 00:00:00.100 (100 ms). Intervals increment up to maxPollingInterval. The default value of maxPollingInterval is 00:01:00 (1 min). maxPollingInterval must not be less than 00:00:00.100 (100 ms). In Functions 2.x and later, the data type is a TimeSpan. In Functions 1.x, it is in milliseconds.
visibilityTimeout
00:00:00
The time interval between retries when processing of a message fails.
batchSize
The number of queue messages that the Functions runtime retrieves simultaneously and processes in parallel. When the number being processed gets down to the newBatchThreshold, the runtime gets another batch and starts processing those messages. So the maximum number of concurrent messages being processed per function is batchSize plus newBatchThreshold. This limit applies separately to each queue-triggered function. 

If you want to avoid parallel execution for messages received on one queue, you can set batchSize to 1. However, this setting eliminates concurrency as long as your function app runs only on a single virtual machine (VM). If the function app scales out to multiple VMs, each VM could run one instance of each queue-triggered function.

The maximum batchSize is 32.
maxDequeueCount
The number of times to try processing a message before moving it to the poison queue.
newBatchThreshold
N*batchSize/2
Whenever the number of messages being processed concurrently gets down to this number, the runtime retrieves another batch.

N represents the number of vCPUs available when running on App Service or Premium Plans. Its value is 1 for the Consumption Plan.
messageEncoding
base64
This setting is only available in extension bundle version 5.0.0 and higher. It represents the encoding format for messages. Valid values are base64 and none.
Next steps
Run a function as queue storage data changes (Trigger)
Write queue storage messages (Output binding)
			Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.

        
Submit and view feedback for
                    This product