azure-functions-core-tools
azure-functions-core-tools copied to clipboard
An item with the same key has already been added. Key: AZURE_FUNCTIONS_ENVIRONMENT
Core Tools version: 3.0.3233 Function Runtime Version: 3.0.15193.0
Repro steps
- Fetch function app configuration from Azure function in azure portal which has AZURE_FUNCTIONS_ENVIRONMENT set
- Start Azure function locally via Rider run
Expected behavior
Azure function should start up normally and read the AZURE_FUNCTIONS_ENVIRONMENT variable from previously fetched local.settings.json
Actual behavior
Function does not start locally, as the fails to add the AZURE_FUNCTIONS_ENVIRONMENT variable again.
"An item with the same key has already been added. Key: AZURE_FUNCTIONS_ENVIRONMENT"
Known workarounds
Workarund is to remove the AZURE_FUNCTIONS_ENVIRONMENT variable from local.settings.json after fetching the settings from the portal to continue developing it locally.
Related information
Using Rider 2020.3.2 and developing in C#/dotnet
AZURE_FUNCTIONS_ENVIRONMENT should work as any other env variable in my opinion. When it's set in a system/user level, it should get it from there, if not, grab it from local.settings.json. Or at least, it should not stop the function from starting.
I am wondering that this problem isn't more common, as I suspect everyone has set AZURE_FUNCTIONS_ENVIRONMENT in his azure function appsettings in Azure(?) and at least a few use the fetch app settings method to generate local.settings.json to work locally
Maybe I am doing something wrong, please let me know
@gzuber could you please take a look at this?
I hit this issue today as well. All I did was add AZURE_FUNCTIONS_ENVIRONMENT to the local.settings.json:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
"AZURE_FUNCTIONS_ENVIRONMENT": "Development",
"ServiceBusConnection": "****"
}
}
This is the result:

The issue still exists. I have to use a custom variable now instead of AZURE_FUNCTIONS_ENVIRONMENT which was exactly designed for the task.
I am experiencing the same issue. As a quick fix, I managed to set this variable in launchSettings.json.
But I'm still getting the warning even though I removed AZURE_FUNCTIONS_ENVIRONMENT variable from local.settings.json
@the-rule - Thanks for providing your workaround! Worked for me.
Well, let's first state the following facts:
local.settings
{
"Values": {
"AZURE_FUNCTIONS_ENVIRONMENT": "Development"
}
}
leading to "An item with the same key has already been added" exception at start time and having a "Production" EnvironmentName.
launchSettings.json
{
"profiles": {
"...": {
"environmentVariables": {
"AZURE_FUNCTIONS_ENVIRONMENT": "Development"
}
}
}
}
leading to "Skipping 'AZURE_FUNCTIONS_ENVIRONMENT' from local settings as it's already defined in current environment variables." at start time and still having a "Production" EnvironmentName.
I want to state, that "AZURE_FUNCTIONS_*" environment are added to IConfigurationBuilder via config.AddEnvironmentVariables("AZURE_FUNCTIONS_"); (compare https://github.com/Azure/azure-functions-dotnet-worker/blob/119843320cb0899ad9f96870dbb0ae264ecb2d7d/src/DotNetWorker/Hosting/WorkerHostBuilderExtensions.cs#L157), so AZURE_FUNCTIONS_ENVIRONMENT ultimately becomes "ENVIRONMENT", but due to the fact we not use WebApplication.CreateBuilder(args) which respects ASPNETCORE_ENVIRONMENT, but FunctionsApplicationBuilder (internally HostApplicationBuilder), and according to the source code of how HostApplicationBuilder resolves its environment and sets it, it is clear that FunctionsApplicationBuilder does not try to initialize HostApplicationBuilderSettings.EnvironmentName once again after HostApplicationBuilder tried to initialize it.
So the simple solution is to not use ASPNETCORE_ENVIRONMENT or AZURE_FUNCTIONS_ENVIRONMENT but DOTNET_ENVIRONMENT. 😆
DOTNET_ENVIRONMENT
Unfortunately, this did not work for me. Got a tons of errors, which is probably related to configurations in other projects referenced by my Functions project.
👋 Just ran into this issue in 2025 using the latest Azure Functions Core Tools with Python v2 and Azurite. Still hitting the same error:
✅ Confirmed that:
AZURE_FUNCTIONS_ENVIRONMENTis only present once inlocal.settings.json- It is not set in PowerShell, Bash, or any other shell environment
- Running
func settings listshows no duplicate - Removing it from
local.settings.jsonis the only workaround that unblocksfunc start
This is incredibly frustrating because it breaks a very standard and documented setup for local dev. The issue has been open since 2021 and still causes confusion and wasted time in 2025. 😤
Please fix this or at least make Core Tools gracefully ignore duplicate keys when they're functionally harmless like this one.
Thanks.