Welcome to today’s blog.
I will show how to enable and conduct debugging of your Azure Blob Trigger function.
In today’s post I will show the two types of debugging: remote and local.
For remote debugging of Azure Functions, you will need the following:
- An existing Azure Trigger Function deployed to an Azure App Service under the consumption hosting plan.
- An existing Azure Storage account.
- An existing Blob container within the storage account.
- An existing Azure Trigger Function implemented locally.
To debug remotely, we first run the locally hosted Azure Function from Visual Studio.
The function app is by default hosted on port 7071 as shown:
Next, we upload a file from an Azure container.
We navigate to the Azure Storage account within the Blob Container.
After we have upload the fie we return back to the locally hosted Azure function, and observe the events in the console:
The debugger should hit any breakpoints you have set within the source for the trigger function:
In order for the Azure function trigger to detect the change within the blob container, the path to the Blob being uploaded requires a path that corresponds to existing storage containers within the storage account. In the above upload we have a storage container bookloantriggerblobs and another storage container data.
Our path within our BlobTrigger attribute declaration in this case is:
The blog trigger storage path is shown in the trigger event handler below:
I will demonstrate local debugging for Azure Functions.
With local debugging we require the following:
- Azure Storage Emulator on your local machine.
- A Blob Container created within the Storage Emulator.
- An existing Azure Trigger Function configured and implemented locally.
Before we can start debugging the local Azure Function, we will need to firstly initialize and start the Azure Storage Emulator. We do this as follows:
Open a command prompt in Administrator mode.
Navigate to folder:
C:\Program Files (x86)\Microsoft SDKs\Azure\Storage Emulator
Enter the command:
This will create the Azure Storage Emulator datastore into an Express database locally as shown:
Next, run the command to start the storage emulator:
The Azure storage emulator can also be opened from the Start Menu:
Next, we will need to confirm the Blob container can access port 10000 so that it can run within the Cloud Explorer within Visual Studio. The following command should show port 10000 running locally:
netstat -na | find “10000”
After the storage emulator has been configured, open the Cloud Explorer within Visual Studio and open the emulated storage account (Development) (Key) as shown:
We then retrieve the connection string to the emulated storage as follows:
Take the above local connection string and update the local.settings.json file and name it to distinguish it from the existing connection strings:
Important Note: If we simply re-used the same connection string as the existing Azure storage connection string, we could have a problem here – If we have currently set any environment variables for our connection string, these will override any existing connection strings from the settings configuration file. For localized debugging, we use a new connection string name and use the same name within the function parameter connection attribute:
We then create the blob container within our storage emulator as shown:
Ensure the name of the blob container matches the path within our trigger function declaration.
One anomaly I have discovered is that within the Cloud Explorer, the storage emulated account does not permit nested blob containers – creating a storage container within an existing storage container, however this can be done within the Azure Storage container in the portal.
Following the creation of the blob container, we start the locally hosted Azure function host from Visual Studio and commence debugging.
To upload the blob we open the blob container from the Cloud Explorer, and once opened it will display a small window:
Click on the icon show to upload a local file. Once upload starts the progress will show below:
Once the upload completes within the container, the break point should be hit within the code:
Upon continuing the debug breakpoint, the console will display the blob creation execution notification and the log output from the trigger function as shown:
We can verify the blob container has the uploaded file with a size and last modified date as shown:
That’s all for today’s post.
I hope you found it useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.