Azure Functions Core Tools

The Azure Functions runtime (runtime for short) is part of Azure Functions Core Tools, a set of Command-Line Interface (CLI) tools that allow you to run, test, and deploy your functions and that you can install on your PC or server.

There are two versions of Azure Function Core Tools:

• Version 1.x: This version can run only on Windows and supports version 1.x of the Azure Functions runtime. It supports .NET Framework 4.7.1 only.
• Version 2.x: This version can run on Windows, macOS, and Linux and supports the 2.x version of the Azure Functions runtime.

The 2.x version of the tool contains the 2.x version of the Azure Functions runtime. It is based on .NET Core and can run on all platforms that support .NET Core 2.x and 3.x (Windows, macOS, and Linux).

The first step to use the tool is, therefore, to install .NET Core on your machine. You can install the tool in different ways depending on whether you are on Windows, macOS, or Linux.

If you are on Windows, you can use Chocolatey or npm.

Chocolatey and npm are two package managers for Windows: using them, you can install tools and applications using CLI (you don't need to care about finding the right installation package, download it and install):

1. For example, to install the latest version of Azure Functions Core Tools using Chocolatey, you can open Command Prompt and write the following command:

C:>choco install azure-functions-core-tools

1. If you prefer npm, you can open Command Prompt and write this command:

C:>npm install -g azure-functions-core-tools

1. If you are on macOS, you have to use Homebrew:

brew tap azure/functions
brew install azure-functions-core-tools

1. Finally, if you are on Linux (Ubuntu or Debian), you have to use APT, and in particular, you have to register the Microsoft product key as a trusted key:

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg

1. Then, you can add the APT source and install the package:

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'
sudo apt-get update
sudo apt-get install azure-functions-core-tools

Of course, you can also use a more productive tool, such as Visual Studio or Visual Studio Code, but it's important to understand that you can perform all the basic operations using Azure Functions Core Tools and that all your functions run inside the Azure Functions runtime.

Once you install the tools, you can start your journey into the Azure Functions development world.

You can show the help for Azure Function Core Tools by merely running the func command (without any parameters):

C:\MasteringServerless>func

The following screenshot shows the output of the preceding command:

As you can see, Azure Function Core Tools has the concept of context; the context is the scope in which you want to work, for example, function is the context to manage Azure Functions, while durable is the context to work on Azure Durable Functions.

The scope mentioned earlier (the context) is why the name is Azure Functions Core Tools, and you can imagine every single context as a separate tool that works on a particular scope. You can show the help for each context using the following command:

C:\MasteringServerless>func <context>

For example, if you try to get help for the function context, Azure Functions Core Tools generates the following output:

The context isn't mandatory because Azure Function Core Tools has a set of commands that are common for every context; for example, if you want to create a function app to host all your functions, you can use the following command:

C:\MasteringServerless\MyFirstFunctionApp>func init --worker-runtime dotnet

This command initializes inside the current folder (in the previous snippet, the MyFirstFunctionApp folder), your functions project, so before you create your first project, you should create the folder that will contain it.

The init command has many arguments but the only one that is mandatory, –-worker-runtime, which allows you to choose which type of programming language you want to use.

When the command completes its job, you will find a bunch of files in the folder:

The project directory contains the host.json and local.settings.json files and the .gitignore file configured for Visual Studio, and, of course, the .csproj project file.

You can consider this directory as equivalent to the function app in Azure.

If you choose to use Azure Functions version 2.x (the default version for Azure Functions Core Tools), every function in the app function must be developed using the same programming language (C# in the previous sample), so you must declare what type of language you want to use (the –-worker-runtime option in the init command). In version 1.x, you must specify the language each time you create a function, not when you create the function app.

To complete your job, you must create an Azure Function, and you can do this using another command of Azure Functions Core Tools:

C:\MasteringServerless\MyFirstFunctionApp>func function new --template HttpTrigger --name MyHttpFunction

When you use the new option, you must specify the template you want to use to create the function (in the previous sample, we created an HTTP trigger function) and, of course, the function name. If you don't specify the necessary parameters, the tools will prompt you.

The command creates a .cs file containing the code for the Azure Function, but don't update the project file to add the new function to the project—you need to update the project file only if you want to work on the project using Visual Studio (or Visual Studio Code); otherwise, you can run your function using the following Azure Functions Core Tools command:

C:\MasteringServerless\MyFirstFunctionApp>func host start

In this case, the tool restores the NuGet packages and builds the project as shown in the following screenshot:

If the build succeeds, then the tool starts the Azure Functions runtime to host the function:

When the Azure Functions runtime starts, it scaffolds your assemblies to find all the Azure Functions and shows them in the console log, so you can immediately check whether all your implementations are OK. If the Azure Functions runtime finds issues in some functions (for example, you are using a binding, and it isn't configured in the right way), it excludes the functions from the scaffolding, shows you a warning in the log console, and you cannot use them.

As you can see in the previous screenshot, MyHttpFunction is listening on the http://localhost:7071/api/MyHttpFunction endpoint, and you can try to execute an HTTP GET:

C:>curl –get http://localhost:7071/api/MyHttpFunction?name=MasteringServerless

If you do, you will see this Azure Functions response:

Moreover, you can see that the Azure Functions runtime instance you started before still shows the function log during its execution.

You can also use the Azure Functions runtime to host precompiled functions: you can copy the entire output folder (the bin folder generated by the build process) and start to host your functions running the host command with the –-script-root option:

C:> func host start --script-root C:\MasteringServerless\PrecompiledFolder

In this way, you can host your functions outside the Azure environment.

One of the important innovations introduced with Azure Functions 2.0 is the possibility of referencing triggers and bindings only when needed. Azure Functions 2.0 introduces the concept of extension, for example, if you want to use an Azure Cosmos DB binding, you must reference the Microsoft.Azure.WebJobs.Extensions.CosmosDB package. You can do this with the Azure Functions Core Tool command:

C:\MasteringServerless\MyFirstAppFunction>func extensions install --package Microsoft.Azure.WebJobs.Extensions.CosmosDB --version 3.0.3

In this case, the tool updates the project file to add the NuGet package reference and creates the extension.json file inside the output folder. The extension.json file contains all the information the runtime needs to use the extensions you referred to.

You can find more information about extensions and the extensions engine later in next chapter.