As we look ahead toward .NET 7, it’s a good time to provide an update on the isolated worker model and how we are thinking about the .NET roadmap for Azure Functions. In a previous post, we introduced the isolated process model, which decouples your function code from the core Azure Functions host, in contrast to the traditional model where we run them together in the same process. Functions V4 supports .NET 6 in both models, and the isolated process model also supports .NET 7 (public preview) and Framework 4.8 (public preview). In this update, we’ll re-cap some of our recent updates, outline some changes to look forward to, and expand on our thinking about future versions.
We will provide another roadmap update in early 2023.
One of the strengths of the isolated process model is that you can just switch the `TargetFramework` for your project to try out new .NET versions. You’re also separately in control of the version of the Functions experience and can take changes there completely independently if you want to stay on a given framework version.
We remain committed to providing day-1 support for future LTS and non-LTS .NET versions. Our intent is to eventually phase out the in-process model, but the timeline for this is not fixed and depends upon improvements we will cover later in this post.Until those improvements to the isolated process model have been made, we will continue to add in-process support for new .NET LTS releases.
The previous post implied a specific timeline for phasing out the in-process model, with .NET 8 only supported on the isolated process model, which is possible but not guaranteed. That change would only occur if the isolated process has reached sufficient parity with the in-process model as outlined in this post. If it does not, there would be an in-process version of .NET 8 support.
We will announce this transition before the initial preview of the first impacted LTS version. Parity will have to have been reached before then; it will be possible at that point to seamlessly uprade an app on the in-process model to its corresponding isolated process model for that .NET version. There will be no compromise in experience resulting from this transition. With that said, you will have plenty of time to navigate the transition as works best for your process and schedule. All .NET LTS versions receive patches for 3 years, so whenever this transition occurs, the last in-process version would still be supported for a full year after the release of the first LTS version that only supports the isolated process model.
A reminder about older versions
Azure Functions support for a given version of a stack ends when formal support for that stack ends. Because .NET Core 3.1 will reach end of support on December 13, 2022, that date is also end of support for function apps targeting .NET Core 3.1. Support for .NET Core 2.2 has already ended, but some apps compiled against it were able to be moved at runtime to .NET Core 3.1, and they will also now be impacted. If your function app is running on Functions V2 or V3, you should plan to move to .NET 6 on Functions V4 to ensure that you receive security updates and have access to the latest features of .NET and Azure Functions.
If you have apps targeting .NET Framework 4.8 on Functions V1, you should also consider migrating those to V4 to take advantage of newer features and dependencies. Many apps on V1 should be able to move to .NET 6 on Functions V4 today. If an app does need .NET Framework 4.8 for any reason, it will be able to move to the isolated process model once support for that framework is generally available in Functions V4.
Be sure to check out our migration guidance for summaries of changes between versions and step-by-step instructions.