Deploying a dotnet-isolated function app with 3.50.0 breaks all functions

[Grimeh]

Hi there!

Ran into a pretty severe issue this afternoon when I deployed our function app from Rider and it broke the app with a "found no functions with runtime 'DOTNET'" error visible in Azure portal.

Description

Looks like Azure Tools plugin will stomp the value of FUNCTIONS_WORKER_RUNTIME for function apps on deploy, defaulting to DOTNET if local.settings.json isn't found.

This wouldn't be a problem if local.settings.json was present and correctly configured, unfortunately it seems like the VS Code Azure extension (other Azure plugins probably also do this) automatically initialises the .gitignore of new Azure projects with local.settings.json ignored. So if you clone a Azure function app, chances are there will be no local.settings.json and deploying will stomp FUNCTIONS_WORKER_RUNTIME with DOTNET, potentially breaking the function app.

555 actually seems to identify this issue and propose a solution.

Workaround

The workaround for 3.50.0 is manually creating a local.settings.json and setting the correct value for worker runtime, however it's not trivial to identify out that solution if you're new to Azure and have no way to know that local.settings.json is missing.

Solution

I don't know what the timeline looks like for a stable 4.0 release, but since I've run into unrelated issues using the 4.0 preview preventing me from deploying I think it's worth considering a fix for 3.50. Eg. implementing #555 or adding a way to disable writing to FUNCTIONS_WORKER_RUNTIME for existing apps.

[rafaelldi]

Hi! The first stable release of v4 will be available in a week or two. In the v4 plugin, the default runtime value is DOTNET-ISOLATED. If I have enough resources, I will implement this fix in v3.50 as well.

[rafaelldi]

The new version is now available, please try it.