Azure-functions-core-tools: Can't determine project language from files

[garrytrinder]

When F5 debugging in Visual Studio 2019, I get multiple warnings from the CLI tools not being able to determine the project language, but the function is hosted locally with no issues and can be triggered, but the Hosting Environment is set to Production.

Azure Function Project is netcoreapp3.1, in a solution with a class library which is netstandard2.0, the Azure Function project is set as the Startup Project.

If I use func start --csharp from the command line, I don't get any warnings and the Hosting Environment is set to Development.

Any ideas on where Visual Studio 2019 is getting things wrong?

[ankitkumarr]

@garrytrinder, do you happen to be missing local.settings.json in your function app directory? If so, I would recommend you run func init in the function app directory and select dotnet and retry.

[msftbot[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[garrytrinder]

Thanks for the reply @ankitkumarr

I'll check back in tomorrow on this, the project in question is a work project and I have just had a few weeks leave, returning tomorrow, so will provide a further update then.

[alexszym]

I had a similar issue even though I do have local.settings.json. Adding FUNCTIONS_WORKER_RUNTIME to it solved the issue for me.
https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#functions_worker_runtime

[RDavis3000]

Mine was caused by having a semi-colon at the end of a key-value-pair instead of a comma in my local.settings.json file. Not a great error message :)

[aqueenan]

If local.settings.json contains information that's always required, why is it added to .gitignore?

[asears]

Local.settings.json may (but shouldn't) include secrets or sensitive information if not using key vault references, environment variables or alternative approach. By default this also includes the storage keys used for the function host runtime under AzureWebJobsStorage, if not using UseDevelopmentStorage=true and Azure Storage Emulator or Azurite.

This was a bad design decision IMO as sharing local settings is usually essential for each dev to get setup with the proper app settings locally. Would have been beneficial to split secrets from settings from the get-go and store secrets encrypted locally at rest by default. The means to resolve them locally from a Key Vault instance per developer or an encrypted, trusted store would also be helpful.

A local key vault would be a helpful addition to the developer stack for Azure Functions, and allow for easier portability between localhost and Azure environments. Unfortunately we don't have this yet.
https://github.com/Azure/Azure-Functions/issues/638

Some links which detail how to set up local.settings.json and managing secrets in various ways.

https://www.tomfaltesek.com/azure-functions-local-settings-json-and-source-control/

https://stackoverflow.com/questions/53029087/how-to-properly-handle-secrets-in-a-local-settings-json-file-when-adding-the-fun

https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-5.0&tabs=windows

https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local?tabs=windows%2Ccsharp%2Cbash

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/preventing-leaked-azure-secrets-in-github/ba-p/1400010

To keep on topic, I have same issue starting functions runtime for Python. Have to specify func start --python even though local settings file contains FUNCTIONS_WORKER_RUNTIME python setting.

[codermrrob]

For me was because of nested configuration setting, forgot it wasn't supported....

[MaximeMorin-Devolutions]

@RDavis3000 Thank you, I had the same message but my file had an extra curly brace at the end. I guess an invalid JSON will show this error.

[stewartadam]

If local.settings.json contains information that's always required, why is it added to .gitignore?

+1. Without FUNCTIONS_WORKER_RUNTIME defined in local.settings.json, func start or func azure functionapp publish will complain about unknown language.

Annoyingly, --csharp and the other parameters are entirely unsupported on func azure functionapp publish, so you just get a broken function app - but that's a separate issue [edit: I can't seem to repro this anymore after calling func init again, but initially it was failing with 'unknown argument' when I tried to add --csharp to the az azure functionapp publish]

If one does check in local.settings.json into Git (so that the others and the pipeline have the default values for FUNCTIONS_WORKER_RUNTIME and can deploy successfully), you can't tell Git to ignore future modifications that file -- as developers add additional configuration settings and/or their secrets to it, it'll get staged. So local.settings.json does need to stay in .gitignore.

@ankitkumarr the defaults from func init produce an environment that works for a developer but will fail on everyone else after checked into Git. If the handful of defaults in local.settings.json are required to build and deploy but that file added to .gitignore by default Git, then consider also producing a local.settings.json.sample file so that can be checked into Git and it's clear what magic settings need to be in local.settings.json to setup a local instance or publish a deployment after cloning the function.