azure-functions-core-tools: Can't determine project language from files
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?
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 21 (4 by maintainers)
For me was because of nested configuration setting, forgot it wasn’t supported…
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
If local.settings.json contains information that’s always required, why is it added to .gitignore?
@garrytrinder, do you happen to be missing
local.settings.json
in your function app directory? If so, I would recommend you runfunc init
in the function app directory and selectdotnet
and retry.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 😃
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.
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 ?
+1. Without
FUNCTIONS_WORKER_RUNTIME
defined inlocal.settings.json
,func start
orfunc azure functionapp publish
will complain about unknown language.Annoyingly,
--csharp
and the other parameters are entirely unsupported onfunc 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 callingfunc init
again, but initially it was failing with ‘unknown argument’ when I tried to add--csharp
to theaz azure functionapp publish
]If one does check in
local.settings.json
into Git (so that the others and the pipeline have the default values forFUNCTIONS_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. Solocal.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 inlocal.settings.json
are required to build and deploy but that file added to.gitignore
by default Git, then consider also producing alocal.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.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 infunc start --python
:To work around this bug, I had to create a local.settings.json with the following content:
Very annoying that people who clone the project will also have to do this.
@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.
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.
@garrytrinder are you still experiencing this issue?