azure-functions-core-tools icon indicating copy to clipboard operation
azure-functions-core-tools copied to clipboard

An item with the same key has already been added. Key: AZURE_FUNCTIONS_ENVIRONMENT

Open johnfriedrich opened this issue 4 years ago • 5 comments

Core Tools version: 3.0.3233 Function Runtime Version: 3.0.15193.0

Repro steps

  1. Fetch function app configuration from Azure function in azure portal which has AZURE_FUNCTIONS_ENVIRONMENT set
  2. 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

johnfriedrich avatar Feb 22 '21 11:02 johnfriedrich

@gzuber could you please take a look at this?

apawast avatar Mar 04 '21 18:03 apawast

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:

image

Matthewsre avatar Jun 01 '21 00:06 Matthewsre

The issue still exists. I have to use a custom variable now instead of AZURE_FUNCTIONS_ENVIRONMENT which was exactly designed for the task.

SoulKa avatar Jul 27 '23 06:07 SoulKa

I am experiencing the same issue. As a quick fix, I managed to set this variable in launchSettings.json. image

But I'm still getting the warning even though I removed AZURE_FUNCTIONS_ENVIRONMENT variable from local.settings.json image

the-rule avatar Nov 24 '23 14:11 the-rule

@the-rule - Thanks for providing your workaround! Worked for me.

StevenRasmussen avatar Apr 24 '24 16:04 StevenRasmussen

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. 😆

teneko avatar Dec 20 '24 11:12 teneko

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.

IngweLand avatar Mar 03 '25 00:03 IngweLand

👋 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_ENVIRONMENT is only present once in local.settings.json
  • It is not set in PowerShell, Bash, or any other shell environment
  • Running func settings list shows no duplicate
  • Removing it from local.settings.json is the only workaround that unblocks func 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.

Sarah-Aly avatar Jul 16 '25 02:07 Sarah-Aly