Local Development Setup: Tools, Debugging, and Hot Reload

Azure Functions for .NET Developers: Series Part 1: Why Azure Functions? Serverless for .NET Developers Part 2: Your First Azure Function: HTTP Triggers Step-by-Step Part 3: Beyond HTTP: Timer, Queue, and Blob Triggers Part 4: Local Development Setup: Tools, Debugging, and Hot Reload ← you are here You add a breakpoint. You press F5. The function executes. The breakpoint never fires. This is the most common introduction to Azure Functions local development. The reason is non-obvious: when you debug a .NET isolated worker function, two separate processes run. Your debugger attached to the host process ( func.exe ) instead of the worker process ( dotnet.exe ), which is where your code actually executes. local.settings.json causes a different kind of confusion. Unlike appsettings.json , it injects environment variables: put a connection string in the wrong section and your bindings silently break. Azurite is a related trap: timer, queue, and blob triggers all use Azure Storage internally,