Understanding the Isolated Worker Model

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 Part 5: Understanding the Isolated Worker Model ← you are here The problem the isolated model solves You add a NuGet reference to Newtonsoft.Json 13.0. Your code compiles. Your unit tests pass. You deploy to Azure Functions, and at runtime, your function silently uses version 12.0.3. No error. No warning. Just the host's copy of the assembly winning the load, because your function code and the Azure Functions runtime shared a single process. This was the in-process model , and for years it was the only way to build .NET Azure Functions. Your function assemblies loaded directly into the same CLR instance as the Functions host. The host pinned its own versions of core packages: Newtonsoft.Json , Microsoft.Ex