Developing and Debug Azure Functions Locally

One of the first things you want to do when you start out developing an Azure Function is to run it and potentially debug issues. You want to see what is going on with your Function before deployment to make sure it is working as intended. Let’s take a look at how to set up Visual Studio (2019 Community Edition) to run Functions locally, see what is going on and debug them.

Setting up yor Environment

To begin, I am assuming you have run through this Microsoft article here. This article gets your environment setup and ready to start local development. Thats the end of this blog post. I’m kidding of course. While this article takes you through the basics of setting up your environment, there are a few things to be aware of that we are going to run through. For starters it’s important to note:

• HTTP triggered functions are generally the easiest to run locally and debug
• Webhook triggered functions, when using services like Event Grid, take a little more work
• Most other Azure service functions will work “out of the box” with cloud resources
• The Azure Storage Emulator (or Azurite) will allow you to replace some cloud resources, but things like Event Grid, Power Apps and Service Bus can’t be debugged locally so you will need external resources for them.

So, depending on the patterns you are implementing, you may need a mix of local and cloud based resources to do development work. Most of the time this is OK as your Functions do all your processing and the other services are your transport mechanism.

Running for the first time

When you first run a Function locally you will see a console window start up with details of the running Functions project. There is a few things I’ve highlighted on this console window:

• Environment - By default Functions will be set to “Development” when run locally and “Production” when deployed
• Listening On - This is the server address and port the Function is listening on if you are using HTTP triggers
• HTTP Functions - A function project can contain more than one function, this are lists all the endpoints that are enabled with HTTP triggers
• Logging Results - Underneath this initial information will be log outputs when the function executes, which can be useful if you don’t want to set breakpoints

Debugging Functions

Once you can run your Functions locally you can just use breakpoints to catch Functions as they progress, however in some cases you might find it better to add informational logging to your suite of functions rather than breakpoints. Normally you don’t have a single function working independently from the rest of your components so you sometimes want to make sure breakpoints don’t disrupt the flow through functions as holding on a breakpoint will timeout triggers like HTTP. You may find it better to log a lot of information and watch the console rather than set a breakpoint.

As far as triggering Functions goes, for HTTP functions you can use a tool like Postman to construct a payload to trigger your Function. For storage triggers you can use the Azure Storage Emulator (or Azurite) to connect to a storage account locally rather than an Azure based resource. For systems where you are using external triggers, a tool like Ngrok (which allows you to proxy your local connections to an external server) come in quite handy, like with EventGrid for example. Ngrok also allows you to see the response codes being generated by your Function which is also quite beneficial.

What next

Next time we will take a look at our logging options, as well as setting up and running automated tests for our Functions.