Work with Azure Functions Core Tools

Prerequisites

To be able to publish to Azure from Core Tools, you must have one of the following Azure tools installed locally:
These tools are required to authenticate with your Azure account from your local computer.
Core Tools versions

Major versions of Azure Functions Core Tools are linked to specific major versions of the Azure Functions runtime. For example, version 4.x of Core Tools supports version 4.x of the Functions runtime. This is the recommended major version of both the Functions runtime and Core Tools. You can find the latest Core Tools release version on this release page .
Run the following command to determine the version of your current Core Tools installation:
func --version
Unless otherwise noted, the examples in this article are for version 4.x.
The following considerations apply to Core Tools versions:
You can only install one version of Core Tools on a given computer.
Version 2.x and 3.x of Core Tools were used with versions 2.x and 3.x of the Functions runtime, which have reached their end of life (EOL). For more information, see Azure Functions runtime versions overview.
Version 1.x of Core Tools is required when using version 1.x of the Functions Runtime, which is still supported. This version of Core Tools can only be run locally on Windows computers. If you're currently running on version 1.x, you should consider migrating your app to version 4.x today.
Install the Azure Functions Core Tools
The recommended way to install Core Tools depends on the operating system of your local development computer.
Windows
macOS
Linux
The following steps use a Windows installer (MSI) to install Core Tools v4.x. For more information about other package-based installers, see the Core Tools readme.
Download and run the Core Tools installer, based on your version of Windows:
v4.x - Windows 64-bit (Recommended. Visual Studio Code debugging requires 64-bit.)
v4.x - Windows 32-bit
If you previously used Windows installer (MSI) to install Core Tools on Windows, you should uninstall the old version from Add Remove Programs before installing the latest version.
If you need to install version 1.x of the Core Tools, see the GitHub repository for more information.
Important
Functions doesn't currently support Python function development on ARM64 devices. To develop Python functions on a Mac with an M1 chip, you must run in an emulated x86 environment. To learn more, see x86 emulation on ARM64.
The following steps use Homebrew to install the Core Tools on macOS.
Install Homebrew, if it's not already installed.
Install the Core Tools package:
brew tap azure/functions
brew install azure-functions-core-tools@4
# if upgrading on a machine that has 2.x or 3.x installed:
brew link --overwrite azure-functions-core-tools@4
The following steps use APT to install Core Tools on your Ubuntu/Debian Linux distribution. For other Linux distributions, see the Core Tools readme.
Install the Microsoft package repository GPG key, to validate package integrity:
curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
Set up the APT source list before doing an APT update.
Ubuntu
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-$(lsb_release -cs)-prod $(lsb_release -cs) main" > /etc/apt/sources.list.d/dotnetdev.list'
Debian
sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/debian/$(lsb_release -rs | cut -d'.' -f 1)/prod $(lsb_release -cs) main" > /etc/apt/sources.list.d/dotnetdev.list'
Check the /etc/apt/sources.list.d/dotnetdev.list file for one of the appropriate Linux version strings in the following table:
Linux distribution
Version
When upgrading to the latest version of Core Tools, you should use the same package manager as the original installation to perform the upgrade. Visual Studio and Visual Studio Code may also install Azure Functions Core Tools, depending on your specific tools installation.
Create a local Functions project
A Functions project directory contains the following files and folders, regardless of language:
File name
Description
local.settings.json
Settings used by Core Tools when running locally, including app settings. To learn more, see local settings.
.gitignore
Prevents the local.settings.json file from being accidentally published to a Git repository. To learn more, see local settings
.vscode\extensions.json
Settings file used when opening the project folder in Visual Studio Code.
To learn more about the Functions project folder, see the Azure Functions developers guide.
In the terminal window or from a command prompt, run the following command to create the project and local Git repository:
func init MyFunctionProj
This example creates a Functions project in a new MyFunctionProj folder. You're prompted to choose a default language for your project.
The following considerations apply to project initialization:
If you don't provide the --worker-runtime option in the command, you're prompted to choose your language. For more information, see the func init reference.
When you don't provide a project name, the current folder is initialized.
If you plan to deploy your project as a function app running in a Linux container, use the --docker option to make sure that a Dockerfile is generated for your project. To learn more, see Create a function app in a local container. If you forget to do this, you can always generate the Dockerfile for the project later by using the func init --docker-only command.
Core Tools lets you create function app projects for the .NET runtime as either in-process or isolated worker process C# class library projects (.csproj). These projects, which can be used with Visual Studio or Visual Studio Code, are compiled during debugging and when publishing to Azure.
Use the --csx parameter if you want to work locally with C# script (.csx) files. These files are the same ones you get when you create functions in the Azure portal and when using version 1.x of Core Tools. To learn more, see the func init reference.
Binding extensions
Functions triggers and bindings are implemented as .NET extension (NuGet) packages. To be able to use a specific binding extension, that extension must be installed in the project.
This section doesn't apply to version 1.x of the Functions runtime. In version 1.x, supported binding were included in the core product extension.
For compiled C# project, add references to the specific NuGet packages for the binding extensions required by your functions. C# script (.csx) project should use extension bundles.
Functions provides extension bundles to make is easy to work with binding extensions in your project. Extension bundles, which are versioned and defined in the host.json file, install a complete set of compatible binding extension packages for your app. Your host.json should already have extension bundles enabled. If for some reason you need to add or update the extension bundle in the host.json file, see Extension bundles.
If you must use a binding extension or an extension version not in a supported bundle, you'll need to manually install extension. For such rare scenarios, see Install extensions.
Local settings
When running in a function app in Azure, settings required by your functions are stored securely in app settings. During local development, these settings are instead added to the Values object in the local.settings.json file. The local.settings.json file also stores settings used by local development tools.
Because the local.settings.json may contain secrets, such as connection strings, you should never store it in a remote repository. To learn more about local settings, see Local settings file.
By default, these settings aren't migrated automatically when the project is published to Azure. Use the --publish-local-settings option when you publish to make sure these settings are added to the function app in Azure. Values in the ConnectionStrings section are never published.
The function app settings values can also be read in your code as environment variables. For more information, see Environment variables.
The function app settings values can also be read in your code as environment variables. For more information, see Environment variables.
The function app settings values can also be read in your code as environment variables. For more information, see Environment variables.
The function app settings values can also be read in your code as environment variables. For more information, see Environment variables.
The function app settings values can also be read in your code as environment variables. For more information, see Environment variables.
When no valid storage connection string is set for AzureWebJobsStorage and a local storage emulator isn't being used, the following error message is shown:
Missing value for AzureWebJobsStorage in local.settings.json. This is required for all triggers other than HTTP. You can run 'func azure functionapp fetch-app-settings <functionAppName>' or specify a connection string in local.settings.json.
Get your storage connection strings
Even when using the Azurite storage emulator for development, you may want to run locally with an actual storage connection. Assuming you have already created a storage account, you can get a valid storage connection string in one of several ways:
Portal
Core Tools
Storage Explorer
From the project root, use one of the following commands to download the connection string from Azure:
Download all settings from an existing function app:
func azure functionapp fetch-app-settings <FunctionAppName>
Get the Connection string for a specific storage account:
func azure storage fetch-connection-string <StorageAccountName>
When you aren't already signed in to Azure, you're prompted to do so. These commands overwrite any existing settings in the local.settings.json file. To learn more, see the func azure functionapp fetch-app-settings and func azure storage fetch-connection-string commands.
Run Azure Storage Explorer.
In the Explorer, expand your subscription, then expand Storage Accounts.
Select your storage account and copy the primary or secondary connection string.
Create a function
To create a function in an existing project, run the following command:
func new
When you run func new, you're prompted to choose a template in the default language of your function app. Next, you're prompted to choose a name for your function. In version 1.x, you're also required to choose the language.




    

You can also specify the function name and template in the func new command. The following example uses the --template option to create an HTTP trigger named MyHttpTrigger:
func new --template "Http Trigger" --name MyHttpTrigger
This example creates a Queue Storage trigger named MyQueueTrigger:
func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger
To learn more, see the func new command.
Run functions locally
To run a Functions project, you run the Functions host from the root directory of your project. The host enables triggers for all functions in the project. Use the following command to run your functions locally:
mvn clean package 
mvn azure-functions:run
func start
The way you start the host depends on your runtime version:
This command must be run in a virtual environment.
When the Functions host starts, it outputs the URL of HTTP-triggered functions, like in the following example:
Found the following functions:
Host.Functions.MyHttpTrigger
Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger
Considerations when running locally
Keep in mind the following considerations when running your functions locally:
By default, authorization isn't enforced locally for HTTP endpoints. This means that all local HTTP requests are handled as authLevel = "anonymous". For more information, see the HTTP binding article. You can use the --enableAuth option to require authorization when running locally. For more information, see func start
While there is local storage emulation available, it's often best to validate your triggers and bindings against live services in Azure. You can maintain the connections to these services in the local.settings.json project file. For more information, see Local settings file. Make sure to keep test and production data separate when testing against live Azure services.
You can trigger non-HTTP functions locally without connecting to a live service. For more information, see Non-HTTP triggered functions.
When you include your Application Insights connection information in the local.settings.json file, local log data is written to the specific Application Insights instance. To keep local telemetry data separate from production data, consider using a separate Application Insights instance for development and testing.
Passing test data to a function
To test your functions locally, you start the Functions host and call endpoints on the local server using HTTP requests. The endpoint you call depends on the type of function.
Examples in this topic use the cURL tool to send HTTP requests from the terminal or a command prompt. You can use a tool of your choice to send HTTP requests to the local server. The cURL tool is available by default on Linux-based systems and Windows 10 build 17063 and later. On older Windows, you must first download and install the cURL tool.
For more general information on testing functions, see Strategies for testing your code in Azure Functions.
HTTP and webhook triggered functions
You call the following endpoint to locally run HTTP and webhook triggered functions:
http://localhost:{port}/api/{function_name}
Make sure to use the same server name and port that the Functions host is listening on. You see an endpoint like this in the output generated when starting the Function host. You can call this URL using any HTTP method supported by the trigger.
The following cURL command triggers the MyHttpTrigger quickstart function from a GET request with the name parameter passed in the query string.
curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks
The following example is the same function called from a POST request passing name in the request body:
You can make GET requests from a browser passing data in the query string. For all other HTTP methods, you must use cURL, Fiddler, Postman, or a similar HTTP testing tool that supports POST requests.
Non-HTTP triggered functions
For all functions other than HTTP and Event Grid triggers, you can test your functions locally using REST by calling a special endpoint called an administration endpoint. Calling this endpoint with an HTTP POST request on the local server triggers the function. You can call the functions administrator endpoint (http://localhost:{port}/admin/functions/) to get URLs for all available functions, both HTTP triggered and non-HTTP triggered.
When running your functions in Core Tools, authentication and authorization is bypassed. However, when you try to call the same administrator endpoints on your function app in Azure, you must provide an access key. To learn more, see Function access keys.
Important
Access keys are valuable shared secrets. When used locally, they must be securely stored outside of source control. Because authentication and authorization isn't required by Functions when running locally, you should avoid using and storing access keys unless your scenarios require it.
To test Event Grid triggered functions locally, see Local testing with viewer web app.
You can optionally pass test data to the execution in the body of the POST request. This functionality is similar to the Test tab in the Azure portal.
You call the following administrator endpoint to trigger non-HTTP functions:
http://localhost:{port}/admin/functions/{function_name}
To pass test data to the administrator endpoint of a function, you must supply the data in the body of a POST request message. The message body is required to have the following JSON format:
    "input": "<trigger_input>"
The <trigger_input> value contains data in a format expected by the function. The following cURL example is a POST to a QueueTriggerJS function. In this case, the input is a string that is equivalent to the message expected to be found in the queue.
Project files
func azure functionapp publish
Deploys function project files directly to your function app using zip deployment.
Kubernetes cluster
func kubernetes deploy
Deploys your Linux function app as a custom Docker container to a Kubernetes cluster.
Before you publish
Important
You must have the Azure CLI or Azure PowerShell installed locally to be able to publish to Azure from Core Tools.
A project folder may contain language-specific files and directories that shouldn't be published. Excluded items are listed in a .funcignore file in the root project folder.
You must have already created a function app in your Azure subscription, to which you can  deploy your code. Projects that require compilation should be built so that the binaries can be deployed.
To learn how to create a function app from the command prompt or terminal window using the Azure CLI or Azure PowerShell, see Create a Function App for serverless execution.
Important
When you create a function app in the Azure portal, it uses version 4.x of the Function runtime by default. To make the function app use version 1.x of the runtime, follow the instructions in Run on version 1.x.
You can't change the runtime version for a function app that has existing functions.
Deploy project files
To publish your local code to a function app in Azure, use the publish command:
func azure functionapp publish <FunctionAppName>
The following considerations apply to this kind of deployment:
Publishing overwrites existing files in the function app.
Use the --publish-local-settings option to automatically create app settings in your function app based on values in the local.settings.json file.
A remote build is performed on compiled projects. This can be controlled by using the --no-build option.
Your project is deployed such that it runs from the deployment package. To disable this recommended deployment mode, use the --nozip option.
To publish to a specific named slot in your function app, use the --slot option.
Java uses Maven to publish your local project to Azure. Instead, use the following command to publish to Azure: mvn azure-functions:deploy. Azure resources are created during initial deployment.
You get an error when you try to publish to a <FunctionAppName> that doesn't exist in your subscription.
Kubernetes cluster
Functions also lets you define your Functions project to run in a Docker container. Use the --docker option of func init to generate a Dockerfile for your specific language. This file is then used when creating a container to deploy. For more information, see Working with containers and Azure Functions.
Core Tools can be used to deploy your project as a custom container image to a Kubernetes cluster.
The following command uses the Dockerfile to generate a container and deploy it to a Kubernetes cluster.
func kubernetes deploy --name <DEPLOYMENT_NAME> --registry <REGISTRY_USERNAME> 
To learn more, see Deploying a function app to Kubernetes.
Install extensions
This section only applies to C# script (.csx) projects, which also rely on extension bundles. Compiled C# projects use NuGet extension packages in the regular way.
In the rare event you aren't able to use extension bundles, you can use Core Tools to install the specific extension packages required by your project. The following are some reasons why you might need to install extensions manually:
You need to access a specific version of an extension not available in a bundle.
You need to access a custom extension not available in a bundle.
You need to access a specific combination of extensions not available in a single bundle.
The following considerations apply when manually installing extensions:
To manually install extensions by using Core Tools, you must have the .NET 6.0 SDK installed.
You can't explicitly install extensions in a function app with extension bundles enabled. First, remove the extensionBundle section in host.json before explicitly installing extensions.
The first time you explicitly install an extension, a .NET project file named extensions.csproj is added to the root of your app project. This file defines the set of NuGet packages required by your functions. While you can work with the NuGet package references in this file, Core Tools lets you install extensions without having to manually edit this C# project file.
Use the following command to install a specific extension package at a specific version, in this case the Storage extension:
func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 5.0.0
You can use this command to install any compatible NuGet package. To learn more, see the func extensions install command.
Monitoring functions
The recommended way to monitor the execution of your functions is by integrating with Azure Application Insights. You can also stream execution logs to your local computer. To learn more, see Monitor Azure Functions.
Application Insights integration
Application Insights integration should be enabled when you create your function app in Azure. If for some reason your function app isn't connected to an Application Insights instance, it's easy to do this integration in the Azure portal. To learn more, see Enable Application Insights integration.
Enable streaming logs
You can view a stream of log files being generated by your functions in a command-line session on your local computer.
Built-in log streaming
Use the func azure functionapp logstream command to start receiving streaming logs of a specific function app running in Azure, as in the following example:
func azure functionapp logstream <FunctionAppName>
Built-in log streaming isn't yet enabled in Core Tools for function apps running on Linux in a Consumption plan. For these hosting plans, you instead need to use Live Metrics Stream to view the logs in near-real time.
Live Metrics Stream
You can view the Live Metrics Stream for your function app in a new browser window by including the --browser option, as in the following example:
func azure functionapp logstream <FunctionAppName> --browser
This type of streaming logs requires that Application Insights integration be enabled for your function app.
x86 emulation on ARM64
Functions doesn't currently support local Python function development on ARM64 devices. Use the following steps to develop Python functions on a Mac with an M1 chip by running in an emulated x86 environment.
Enable Rosetta in Terminal
In your Mac, open Finder, choose Applications, and locate Terminal.
Control-click Terminal and select Get Info. You can also create a separate parallel environment by duplicating the Terminal and renaming it.
Select Open using Rosetta.
Open Terminal, which now has Rosetta enabled, and make sure your shell is zsh.
Run the following command to validate the x86 emulation.
$ arch
A response of i386 indicates your terminal is running an x86 emulated environment. If you aren't yet running in an x86 emulated environment, you may need to restart your local computer.
Install required packages
Reinstall all dependencies required by Functions in this environment, which includes the following packages:
homebrew, installed to the path /usr/local/bin/brew.
Python
Azure Functions Core Tools
Also, reinstall any other packages required by your Python project.
Set aliases (optional)
You can optionally set aliases to make it easy to reference the right versions in Rosetta.
The following is an example of how to create a .zshrc file to configure your zsh terminal:
# file: .zshrc
# rosetta terminal setup
if [ $(arch) = "i386" ]; then
    alias python="/usr/local/bin/python3"
    alias brew86='/usr/local/bin/brew'
    alias pyenv86="arch -x86_64 pyenv"
    alias func="/usr/local/Cellar/azure-functions-core-tools@4/4.0.4785/func"
Run the following command to apply the aliases:
$ source .zshrc
Validate you're referencing the correct versions by using the which command, as shown in the following examples:
Command
Example response
These example responses are based on the previous example .zshrc file.
Now, you're set up to use Azure Functions in the x86 environment from the Terminal.
If you're using Visual Studio Code, you can integrate Rosetta with the built-in Terminal. For more information, see Enable emulation in Visual Studio Code.
Next steps
Learn how to develop, test, and publish Azure functions by using Azure Functions core tools. Azure Functions Core Tools is open source and hosted on GitHub. To file a bug or feature request, open a GitHub issue.