AzureFeeds

This blog post provides a step-to-step guidance for how to debug the Azure WebJobs Extension SDK both locally and remotely on the function app.

As you all know, Azure Function Apps are built on top of the Azure WebJobs SDK, which is an open-source framework that simplifies the task of writing background processing code that runs in Azure. The Azure WebJobs SDK includes a declarative binding and trigger system, commonly referred to as Azure WebJobs Extensions. These extensions allow developers to easily integrate with various Azure services and define how their background tasks respond to events.

If you encounter any issues while using the Azure WebJobs Extensions SDK, the best way to report them is via GitHub Issues. You can report bugs, request features, or ask questions there. When reporting a bug, it’s most efficient to use the default bug template and provide detailed steps to reproduce the issue. Ideally, a minimum reproducible project is preferable. We also recommend creating a pull request (PR) to contribute to the community. Therefore, knowing how to debug the WebJobs Extensions SDK is useful.

In this blog, we’re taking storage extension SDK for an example, for other extensions like service bus or event grid or others, the methodology is the same.

Why debugging storage extension SDK is useful:

1. Understand SDK behavior: The Storage Extension SDK interacts with Azure Blob Storage and Azure Functions, which can lead to complex behaviors. Debugging helps you understand how these components communicate and react to various events.


2. Error Diagnosis: Debugging helps identify issues such as misconfigurations, incorrect connections to storage accounts, unexpected behaviors in blob processing or even performance bottlenecks.


3. Testing Edge Cases: Debugging allows you to simulate various conditions (e.g., network failures, blob size variations) to see how your application handles edge cases, ensuring robustness in production.

As support will end for the dotnet in-process model on Nov 10, 2026, in this blog, we will only focus on debugging extension in isolated worker model. 

Debugging the storage extension locally:

1. Download the source code of the azure webjob storage extension SDK from github releases, at the time when the blog is being written, the storage extension SDK is at 5.3.4 version: Release Microsoft.Azure.WebJobs.Extensions.Storage_5.3.4 · Azure/azure-sdk-for-net · GitHub


2. In VS studio, build the sdkstorageMicrosoft.Azure.WebJobs.Extensions.Storage.BlobssrcMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs.csproj, ensure there is No build error.


3. Create a dotnet isolated function app in VS studio with the default template to create a new blob trigger function, build the project and ensure there is No build error.


4. Copy the artifactsbinMicrosoft.Azure.WebJobs.Extensions.Storage.BlobsDebugnetstandard2.0Microsoft.Azure.WebJobs.Extensions.Storage.Blobs.dll that we built in the step 2 to the azure function project build output folder FunctionAppbinDebugnet8.0.azurefunctions to override the release version (No debugging symbols) of the dll.  


5. In cmd, run “func start –verbose” from FunctionApp8binDebugnet8.0 to start azure function runtime.


6. In VS studio Microsoft.Azure.WebJobs.Extensions.Storage.Blobs project (Step 2), attach debugger to “func” start process.


7. Set break point at ListenersScanBlobScanLogHybridPollingStrategy.cs#ExecuteAsync() and it should be hit when the next regular log scan or container scan occurs.

Debugging the storage extension remotely:

1. Download the source code of the azure webjob storage extension SDK from github releases, at the time when the blog is being written, the storage extension SDK is at 5.3.4 version: Release Microsoft.Azure.WebJobs.Extensions.Storage_5.3.4 · Azure/azure-sdk-for-net · GitHub


2. In VS studio, build the sdkstorageMicrosoft.Azure.WebJobs.Extensions.Storage.BlobssrcMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs.csproj, ensure there is No build error.


3. Create a dotnet isolated function app in VS studio with the default template to create a new blob trigger function, build the project and ensure there is No build error.


4. Deploy the function app using web deploy to Azure by uncheck the “Run from package file” checkbox. The reason why we’re using web deploy (WEBSITE_RUN_FROM_PACKAGE = 0) is because we’ll have to replace the storage extension dll compiled with debugging symbols on the remote function app.


5. Copy the artifactsbinMicrosoft.Azure.WebJobs.Extensions.Storage.BlobsDebugnetstandard2.0Microsoft.Azure.WebJobs.Extensions.Storage.Blobs.dll that we built in the step 2 to the remote function app via Kudu console at C:homesitewwwroot.azurefunctions to override the release version (No debugging symbols) of the dll.  


6. In VS studio Microsoft.Azure.WebJobs.Extensions.Storage.Blobs project (Step 2), attach debugger to the w3wp.exe of the remote function app 


7. Set break point at ListenersScanBlobScanLogHybridPollingStrategy.cs#ExecuteAsync() and it should be hit when the next regular log scan or container scan occurs.

Happy debugging!