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.

[ghost]

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.

[leijae]

My solution was that as I was upgrading between VS 2022 Preview, to VS 2022 RC some of my file properties were changed from "Copy if newer" to "do not copy"... when I changed that setting for local.settings.json it resolved the issue.

[apawast]

@garrytrinder are you still experiencing this issue?

[ghost]

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.

[stewartadam]

@apawast I'm not the original author of the issue but per above, definitely still experiencing this.

It would be nice if local.settings.json was safe to gitignore, but today it needs to be checked in or else language detection fails.

[bkane-msft]

I'm also running into this. I tried to clone my project from Git and ran func azure functionapp publish <appname>. func azure functionapp publish <appname> --python does seem to work.

However, the lack of a local.settings.json will cause the following error in func start --python:

[2021-11-23T22:41:37.240Z] ImportError: cannot import name 'cygrpc' from 'grpc._cython' (/usr/local/Cellar/azure-functions-core-tools@4/4.0.3971/workers/python/3.8/OSX/X64/grpc/_cython/__init__.py)

To work around this bug, I had to create a local.settings.json with the following content:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "python"
  }
}

Very annoying that people who clone the project will also have to do this.

[stewartadam]

pinging @apawast to get this re-opened

[anthonychu]

Created #2848 as a potential solution

[srilalfonseka]

Seems you are missing the project loca.settings.json reference in the project configuration level. Check if you see the follwing in the <Project Sdk="Microsoft.NET.Sdk"> xml and add it if missing. I had the same issue. Not sure how I missed (or got removed) it. It worked.

[ArmandoPitotti]

For me, it was an error on local.settings.json. The comma was missing. I was able to understand the error by the output window build:

"Newtonsoft.Json.JsonReaderException: After parsing a value an unexpected character was encountered: ". Path 'Values.ENDPOINT_SOA_EIH_GC41OUT', line 41, position 4."

[TheWebartist]

I. I am encountering this issue too from Visual Studio Update (from 17.5.3 or 17.5.2 maybe).

My Azure functions project that target .NET6 successfully run localy from my Visual Studio few weeks ago.

And not now, without any changes to my local.settings.json, it's not wokrs.

I have the required keys in settings.json (FUNCTIONS_WORKER_RUNTIME) and valid build action.

A breaking change / regression in the recents versions of Visual Studio ?

Can we have some news please ?

[ganesh-jadhav07]

Thanks @alexszym

[tobiasbunyan]

It seems I had the same problem when trying to use nested properties in the local.settings.json file under the "Values" section. It's not really clear in most of the help docs that this is a restriction, and if it's going to make the function host fall over it should at least be reported as issues with the json file.

Nested values outside of the "Values" section don't affect it, it would seem.

[RichardPoes]

Came here to say this. To clarify, the following won't work (and will give you the vary unclear error above):

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SomeSetting": {
        "This": "WontWork"
        }
    }
}

Buttt this will work, and this is how to fix it:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SomeSetting__This": "WillWork"
    }
}

[edrohler]

Came here to say this. To clarify, the following won't work (and will give you the vary unclear error above):

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SomeSetting": {
        "This": "WontWork"
        }
    }
}

Buttt this will work, and this is how to fix it:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SomeSetting__This": "WillWork"
    }
}

This was my issue after spending all day wondering why in the world would my local.settings.json file not be available in the function runtime. This is why! 🤦‍♂️

I changed the object to match the double underscore and sure enough.. there the settings are.

For reference, the Local Settings section does mention this. It is in the table for the Values setting row.

To use a true JSON object, it should be escaped. "KEY": "{\"PROP1\":\"VAL1\"}"

[nagendramishr]

local.settings.json is supposed to contain local environment information and should not be checked into source control... It seems that the runtime worker runtime variable should not belong in local.settings, rather in host.json , no?