Develop Azure Functions using Visual Studio

Visual Studio lets you develop, test, and deploy C# class library functions to Azure. If this experience is your first with Azure Functions, see An introduction to Azure Functions.

Visual Studio provides the following benefits when you develop your functions:

  • Edit, build, and run functions on your local development computer.
  • Publish your Azure Functions project directly to Azure, and create Azure resources as needed.
  • Use C# attributes to declare function bindings directly in the C# code.
  • Develop and deploy pre-compiled C# functions. Pre-complied functions provide a better cold-start performance than C# script-based functions.
  • Code your functions in C# while having all of the benefits of Visual Studio development.

This article provides details about how to use Visual Studio to develop C# class library functions and publish them to Azure. Before you read this article, consider completing the Functions quickstart for Visual Studio.

Unless otherwise noted, procedures and examples shown are for Visual Studio 2019.


  • Azure Functions Tools. To add Azure Function Tools, include the Azure development workload in your Visual Studio installation. Azure Functions Tools is available in the Azure development workload starting with Visual Studio 2017.

  • Other resources that you need, such as an Azure Storage account, are created in your subscription during the publishing process.

  • If you don't have an Azure subscription, create a free account before you begin.


In Visual Studio 2017, the Azure development workload installs Azure Functions Tools as a separate extension. When you update your Visual Studio 2017 installation, make sure that you're using the most recent version of the Azure Functions tools. The following sections show you how to check and (if needed) update your Azure Functions Tools extension in Visual Studio 2017.

Skip these sections if you're using Visual Studio 2019.

Check your tools version in Visual Studio 2017

  1. From the Tools menu, choose Extensions and Updates. Expand Installed > Tools, and then choose Azure Functions and Web Jobs Tools.

    Verify the Functions tools version

  2. Note the installed Version and compare this version with the latest version listed in the release notes.

  3. If your version is older, update your tools in Visual Studio as shown in the following section.

Update your tools in Visual Studio 2017

  1. In the Extensions and Updates dialog, expand Updates > Visual Studio Marketplace, choose Azure Functions and Web Jobs Tools and select Update.

    Update the Functions tools version

  2. After the tools update is downloaded, select Close, and then close Visual Studio to trigger the tools update with VSIX Installer.

  3. In VSIX Installer, choose Modify to update the tools.

  4. After the update is complete, choose Close, and then restart Visual Studio.


In Visual Studio 2019 and later, the Azure Functions tools extension is updated as part of Visual Studio.

Create an Azure Functions project

The Azure Functions project template in Visual Studio creates a project that you can publish to a function app in Azure. You can use a function app to group functions as a logical unit for easier management, deployment, scaling, and sharing of resources.

  1. From the Visual Studio menu, select File > New > Project.

  2. In Create a new project, enter functions in the search box, choose the Azure Functions template, and then select Next.

  3. In Configure your new project, enter a Project name for your project, and then select Create. The function app name must be valid as a C# namespace, so don't use underscores, hyphens, or any other nonalphanumeric characters.

  4. For the Create a new Azure Functions application settings, use the values in the following table:

    Setting Value Description
    Functions runtime Azure Functions v3
    (.NET Core)
    This value creates a function project that uses the version 3.x runtime of Azure Functions, which supports .NET Core 3.x. Azure Functions 1.x supports the .NET Framework. For more information, see Azure Functions runtime versions overview.
    Function template HTTP trigger This value creates a function triggered by an HTTP request.
    Storage account (AzureWebJobsStorage) Storage emulator Because an Azure Function requires a storage account, one is assigned or created when you publish your project to Azure. An HTTP trigger doesn't use an Azure Storage account connection string; all other trigger types require a valid Azure Storage account connection string.
    Authorization level Anonymous The created function can be triggered by any client without providing a key. This authorization setting makes it easy to test your new function. For more information about keys and authorization, see Authorization keys and HTTP and webhook bindings.

    Azure Functions project settings

    Make sure you set the Authorization level to Anonymous. If you choose the default level of Function, you're required to present the function key in requests to access your function endpoint.

  5. Select Create to create the function project and HTTP trigger function.

After you create an Azure Functions project, the project template creates a C# project, installs the Microsoft.NET.Sdk.Functions NuGet package, and sets the target framework. The new project has the following files:

  • host.json: Lets you configure the Functions host. These settings apply both when running locally and in Azure. For more information, see host.json reference.

  • local.settings.json: Maintains settings used when running functions locally. These settings aren't used when running in Azure. For more information, see Local settings file.


    Because the local.settings.json file can contain secrets, you must exclude it from your project source control. Ensure the Copy to Output Directory setting for this file is set to Copy if newer.

For more information, see Functions class library project.

Local settings file

The local.settings.json file stores app settings, connection strings, and settings used by local development tools. Settings in the local.settings.json file are used only when you're running projects locally. The local settings file has this structure:

  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "<language worker>",
    "AzureWebJobsStorage": "<connection-string>",
    "AzureWebJobsDashboard": "<connection-string>",
    "MyBindingConnection": "<binding-connection-string>",
    "AzureWebJobs.HttpExample.Disabled": "true"
  "Host": {
    "LocalHttpPort": 7071,
    "CORS": "*",
    "CORSCredentials": false
  "ConnectionStrings": {
    "SQLConnectionString": "<sqlclient-connection-string>"

These settings are supported when you run projects locally:

Setting Description
IsEncrypted When this setting is set to true, all values are encrypted with a local machine key. Used with func settings commands. Default value is false. You might want to encrypt the local.settings.json file on your local computer when it contains secrets, such as service connection strings. The host automatically decrypts settings when it runs. Use the func settings decrypt command before trying to read locally encrypted settings.
Values Array of application settings and connection strings used when a project is running locally. These key-value (string-string) pairs correspond to application settings in your function app in Azure, like AzureWebJobsStorage. Many triggers and bindings have a property that refers to a connection string app setting, like Connection for the Blob storage trigger. For these properties, you need an application setting defined in the Values array. See the subsequent table for a list of commonly used settings.
Values must be strings and not JSON objects or arrays. Setting names can't include a colon (:) or a double underline (__). Double underline characters are reserved by the runtime, and the colon is reserved to support dependency injection.
Host Settings in this section customize the Functions host process when you run projects locally. These settings are separate from the host.json settings, which also apply when you run projects in Azure.
LocalHttpPort Sets the default port used when running the local Functions host (func host start and func run). The --port command-line option takes precedence over this setting.
CORS Defines the origins allowed for cross-origin resource sharing (CORS). Origins are supplied as a comma-separated list with no spaces. The wildcard value (*) is supported, which allows requests from any origin.
CORSCredentials When set to true, allows withCredentials requests.
ConnectionStrings A collection. Don't use this collection for the connection strings used by your function bindings. This collection is used only by frameworks that typically get connection strings from the ConnectionStrings section of a configuration file, like Entity Framework. Connection strings in this object are added to the environment with the provider type of System.Data.SqlClient. Items in this collection aren't published to Azure with other app settings. You must explicitly add these values to the Connection strings collection of your function app settings. If you're creating a SqlConnection in your function code, you should store the connection string value with your other connections in Application Settings in the portal.

The following application settings can be included in the Values array when running locally:

Setting Values Description
AzureWebJobsStorage Storage account connection string, or
Contains the connection string for an Azure storage account. Required when using triggers other than HTTP. For more information, see the AzureWebJobsStorage reference.
When you have the Azure storage emulator installed locally and you set AzureWebJobsStorage to UseDevelopmentStorage=true, Core Tools uses the emulator. The emulator is useful during development, but you should test with an actual storage connection before deployment.
AzureWebJobs.<FUNCTION_NAME>.Disabled true|false To disable a function when running locally, add "AzureWebJobs.<FUNCTION_NAME>.Disabled": "true" to the collection, where <FUNCTION_NAME> is the name of the function. To learn more, see How to disable functions in Azure Functions
Indicates the targeted language of the Functions runtime. Required for version 2.x and higher of the Functions runtime. This setting is generated for your project by Core Tools. To learn more, see the FUNCTIONS_WORKER_RUNTIME reference.
FUNCTIONS_WORKER_RUNTIME_VERSION ~7 Indicates that PowerShell 7 be used when running locally. If not set, then PowerShell Core 6 is used. This setting is only used when running locally. When running in Azure, the PowerShell runtime version is determined by the powerShellVersion site configuration setting, which can be set in the portal.

Visual Studio doesn't automatically upload the settings in local.settings.json when you publish the project. To make sure that these settings also exist in your function app in Azure, upload them after you publish your project. For more information, see Function app settings. The values in a ConnectionStrings collection are never published.

Your code can also read the function app settings values as environment variables. For more information, see Environment variables.

Configure the project for local development

The Functions runtime uses an Azure Storage account internally. For all trigger types other than HTTP and webhooks, set the Values.AzureWebJobsStorage key to a valid Azure Storage account connection string. Your function app can also use the Azure Storage Emulator for the AzureWebJobsStorage connection setting that's required by the project. To use the emulator, set the value of AzureWebJobsStorage to UseDevelopmentStorage=true. Change this setting to an actual storage account connection string before deployment.

To set the storage account connection string:

  1. In Visual Studio, select View > Cloud Explorer.

  2. In Cloud Explorer, expand Storage Accounts, and then select your storage account. In the Properties tab, copy the Primary Connection String value.

  3. In your project, open the local.settings.json file and set the value of the AzureWebJobsStorage key to the connection string you copied.

  4. Repeat the previous step to add unique keys to the Values array for any other connections required by your functions.

Add a function to your project

In C# class library functions, the bindings used by the function are defined by applying attributes in the code. When you create your function triggers from the provided templates, the trigger attributes are applied for you.

  1. In Solution Explorer, right-click your project node and select Add > New Item.

  2. Select Azure Function, enter a Name for the class, and then select Add.

  3. Choose your trigger, set the binding properties, and then select OK. The following example shows the settings for creating a Queue storage trigger function.

    Create a Queue storage trigger function

    This trigger example uses a connection string with a key named QueueStorage. Define this connection string setting in the local.settings.json file.

  4. Examine the newly added class. You see a static Run() method that's attributed with the FunctionName attribute. This attribute indicates that the method is the entry point for the function.

    For example, the following C# class represents a basic Queue storage trigger function:

    using System;
    using Microsoft.Azure.WebJobs;
    using Microsoft.Azure.WebJobs.Host;
    using Microsoft.Extensions.Logging;
    namespace FunctionApp1
        public static class Function1
            public static void Run([QueueTrigger("myqueue-items", 
                Connection = "QueueStorage")]string myQueueItem, ILogger log)
                log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");

A binding-specific attribute is applied to each binding parameter supplied to the entry point method. The attribute takes the binding information as parameters. In the previous example, the first parameter has a QueueTrigger attribute applied, indicating a Queue storage trigger function. The queue name and connection string setting name are passed as parameters to the QueueTrigger attribute. For more information, see Azure Queue storage bindings for Azure Functions.

Use the above procedure to add more functions to your function app project. Each function in the project can have a different trigger, but a function must have exactly one trigger. For more information, see Azure Functions triggers and bindings concepts.

Add bindings

As with triggers, input and output bindings are added to your function as binding attributes. Add bindings to a function as follows:

  1. Make sure you've configured the project for local development.

  2. Add the appropriate NuGet extension package for the specific binding.

    For more information, see C# class library with Visual Studio. Find the binding-specific NuGet package requirements in the reference article for the binding. For example, find package requirements for the Event Hubs trigger in the Event Hubs binding reference article.

  3. If there are app settings that the binding needs, add them to the Values collection in the local setting file.

    The function uses these values when it runs locally. When the function runs in the function app in Azure, it uses the function app settings.

  4. Add the appropriate binding attribute to the method signature. In the following example, a queue message triggers the function, and the output binding creates a new queue message with the same text in a different queue.

    public static class SimpleExampleWithOutput
        public static void Run(
            [QueueTrigger("myqueue-items-source", Connection = "AzureWebJobsStorage")] string myQueueItem, 
            [Queue("myqueue-items-destination", Connection = "AzureWebJobsStorage")] out string myQueueItemCopy,
            ILogger log)
            log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
            myQueueItemCopy = myQueueItem;

    The connection to Queue storage is obtained from the AzureWebJobsStorage setting. For more information, see the reference article for the specific binding.

This table shows the bindings that are supported in the major versions of the Azure Functions runtime:

Type 1.x 2.x and higher1 Trigger Input Output
Blob storage
Azure Cosmos DB
Event Grid
Event Hubs
HTTP & webhooks
IoT Hub
Mobile Apps
Notification Hubs
Queue storage
Service Bus
Table storage

1 Starting with the version 2.x runtime, all bindings except HTTP and Timer must be registered. See Register binding extensions.

2 Triggers aren't supported in the Consumption plan. Requires runtime-driven triggers.

3 Supported only in Kubernetes, IoT Edge, and other self-hosted modes only.

Testing functions

Azure Functions Core Tools lets you run Azure Functions project on your local development computer. For more information, see Work with Azure Functions Core Tools. You're prompted to install these tools the first time you start a function from Visual Studio.

To test your function in Visual Studio:

  1. Press F5. If prompted, accept the request from Visual Studio to download and install Azure Functions Core (CLI) tools. You might also need to enable a firewall exception so that the tools can handle HTTP requests.

  2. With the project running, test your code as you would test a deployed function.

    For more information, see Strategies for testing your code in Azure Functions. When you run Visual Studio in debug mode, breakpoints are hit as expected.

Publish to Azure

When you publish from Visual Studio, it uses one of two deployment methods:

Use the following steps to publish your project to a function app in Azure.

  1. In Solution Explorer, right-click the project and select Publish.

  2. In Pick a publish target, use the publish options specified in the following table:

    Option Description
    Azure Functions Consumption Plan Create a function app in an Azure cloud environment that runs in a Consumption plan. When you use a Consumption plan, you pay only for executions of your functions app. Other hosting plans incur higher costs. If you run in a plan other than a Consumption plan, you must manage the scaling of your function app.
    Create New A new function app, with related resources, is created in Azure.
    If you choose Select Existing, all files in the existing function app in Azure are overwritten by files from the local project. Use this option only when you republish updates to an existing function app.
    Run from package file Your function app is deployed using Zip Deploy with Run-From-Package mode enabled. This deployment, which results in better performance, is the recommended way of running your functions.
    If you don't use this option, make sure to stop your function app project from running locally before you publish to Azure.

    Create a publish profile

  3. Select Create Profile. If you haven't already signed-in to your Azure account from Visual Studio, select Sign-in. You can also create a free Azure account.

  4. In App Service: Create new, use the values specified in the following table:

    Setting Value Description
    Name Globally unique name Name that uniquely identifies your new function app. Accept this name or enter a new name. Valid characters are: a-z, 0-9, and -.
    Subscription Your subscription The Azure subscription to use. Accept this subscription or select a new one from the drop-down list.
    Resource group Name of your resource group The resource group in which to create your function app. Select an existing resource group from the drop-down list or choose New to create a new resource group.
    Hosting Plan Name of your hosting plan Select New to configure a serverless plan. Make sure to choose the Consumption under Size. When you publish your project to a function app that runs in a Consumption plan, you pay only for executions of your functions app. Other hosting plans incur higher costs. If you run in a plan other than Consumption, you must manage the scaling of your function app.
    Location Location of the app service Choose a Location in a region near you or other services your functions access.
    Azure Storage General-purpose storage account An Azure Storage account is required by the Functions runtime. Select New to configure a general-purpose storage account. You can also choose an existing account that meets the storage account requirements.

    Create App Service dialog

  5. Select Create to create a function app and its related resources in Azure with these settings and deploy your function project code.

  6. Select Publish and wait for the deployment to complete.

    After the deployment completes the root URL of the function app in Azure is shown in the Publish tab.

  7. In the Publish tab, choose Manage in Cloud Explorer. This opens the new function app Azure resource in Cloud Explorer.

    Publish success message

    Cloud Explorer lets you use Visual Studio to view the contents of the site, start and stop the function app, and browse directly to function app resources on Azure and in the Azure portal.

Function app settings

Because Visual Studio doesn't upload these settings automatically when you publish the project, any settings you add in the local.settings.json you must also add to the function app in Azure.

The easiest way to upload the required settings to your function app in Azure is to select the Manage Azure App Service settings link that appears after you successfully publish your project.

Settings in Publish window

Selecting this link displays the Application settings dialog for the function app, where you can add new application settings or modify existing ones.

Application settings

Local displays a setting value in the local.settings.json file, and Remote displays a current setting value in the function app in Azure. Choose Add setting to create a new app setting. Use the Insert value from Local link to copy a setting value to the Remote field. Pending changes are written to the local settings file and the function app when you select OK.


By default, the local.settings.json file is not checked into source control. This means that if you clone a local Functions project from source control, the project doesn't have a local.settings.json file. In this case, you need to manually create the local.settings.json file in the project root so that the Application settings dialog works as expected.

You can also manage application settings in one of these other ways:

Monitoring functions

The recommended way to monitor the execution of your functions is by integrating your function app with Azure Application Insights. When you create a function app in the Azure portal, this integration is done for you by default. However, when you create your function app during Visual Studio publishing, the integration in your function app in Azure isn't done. To learn how to connect Application Insights to your function app, see Enable Application Insights integration.

To learn more about monitoring using Application Insights, see Monitor Azure Functions.

Next steps

For more information about the Azure Functions Core Tools, see Work with Azure Functions Core Tools.

For more information about developing functions as .NET class libraries, see Azure Functions C# developer reference. This article also links to examples of how to use attributes to declare the various types of bindings supported by Azure Functions.