Why does my newly created .NET 8 azure function use dotnet, while upgraded ones use dotnet-isolated?

Question

Hello all,

I recently migrated a few azure functions from .NET 6.0 to .NET 8.0, mostly using the in place Visual Studio 2022 upgrade process. One of the last steps after upgrading is to update your local.settings.json to this

"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"

This all works great and I haven't had any problems with my functions that went from .NET 6.0 to .NET 8.0. It even worked for .NET CORE 2.0 -> .NET 8.0.

Now when I create a brand new .NET 8.0 Azure function in Visual Studio 2022, the local.settings.json defaults to the value below.

"FUNCTIONS_WORKER_RUNTIME": "dotnet", 

Why is there a difference here? The newly created .NET 8.0 Azure function doesn't create with a program.cs or recognize the one I added upon startup

Many of the nuget packages, dependency injections, and bindings are completely different between the upgraded .NET 6.0 apps, and the brand new .NET 8.0. Because of this, it feels like I'm setting up a completely different app.

Answer 1

@Brendan Finnegan Thanks for reaching out. I tried creating a new .NET8.0 azure function in visual studio 2022 and I see the local.settings.json defaults to "dotnet-isolated" as shown below.

could you please try again, i believe the value has been changed explicitly. Net 8.0 supports both In process and Out process model. Recommendation to use Out process model for long term support. For more details refer this below document

Migrate .NET function apps from the in-process model to the isolated worker model | Microsoft Learn

To use In process model In .net 8.0 , add below settings 

• The application setting FUNCTIONS_WORKER_RUNTIME must be set with the value "dotnet".
• The application setting FUNCTIONS_EXTENSION_VERSION must be set with the value "~4".
• The application setting FUNCTIONS_INPROC_NET8_ENABLED must be set with the value "1".
• You must update the stack configuration to reference .NET 8.

please refer: Develop C# class library functions using Azure Functions | Microsoft Learn

Note: Targeting .NET 8 with the in-process model is not yet enabled for Linux, for apps hosted in App Service Environments, or for apps in sovereign clouds. Updates will be communicated on this tracking thread on GitHub.

Develop C# class library functions using Azure Functions | Microsoft Learn

do let me know incase of further queries, I would be happy to assist you.

Answer 2

Hello @Brendan Finnegan

The difference you’re seeing is due to the two different execution models for .NET functions: the in-process model and the isolated worker model.

The in-process model runs your .NET class library functions in the same process as the Functions host runtime. This is the model that’s used when "FUNCTIONS_WORKER_RUNTIME": "dotnet" is set in your local.settings.json file.

On the other hand, the isolated worker model runs your .NET functions in an isolated worker process. This is the model that’s used when "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated" is set in your local.settings.json file.

When you create a new .NET 8.0 Azure function in Visual Studio 2022, it defaults to the in-process model. However, when you upgraded your existing .NET 6.0 functions to .NET 8.0, you also migrated them to the isolated worker model.

The isolated worker model has several benefits over the in-process model:

• Fewer conflicts: Your functions run in a separate process, so assemblies used in your app don’t conflict with different versions of the same assemblies used by the host process.
• Full control of the process: You control the start-up of the app, which means that you can manage the configurations used and the middleware started.
• Standard dependency injection: You can use current .NET behaviors for dependency injection and incorporating middleware into your function app.
• .NET version flexibility: Your functions can run on versions of .NET not natively supported by the Functions runtime, including the .NET Framework.

The differences in NuGet packages, dependency injections, and bindings that you’re seeing between the upgraded .NET 6.0 apps and the brand new .NET 8.0 app are likely due to the differences between these two execution models.

I hope this helps clarify the difference.

---

I hope that this response has addressed your query and helped you overcome your challenges. If so, please mark this response as Answered. This will not only acknowledge our efforts, but also assist other community members who may be looking for similar solutions.