Azure App Service - What modified my web.config? - azure-web-app-service

Question

I have an ASP.NET Core website running from Kestrel. It is deployed to Azure App Service in production and another as staging.
I like to configure staging as "production-like" so I set ASPNETCORE_ENVIRONMENTNAME = Production in the Configuration blade of the App Service in the Azure portal. I could see from logs that the code was seeing the environment name as staging still.
It turns out <environmentVariable name="ASPNETCORE_ENVIRONMENTNAME" value="staging" /> is set in the web.config that's on the Azure instance!!
Now, I don't have this set in the web.config or any transforms in my codebase, and I don't use the web.config, in fact I want nothing to do with it or IIS.
My site is deployed via Azure Pipelines. I use environmentName as a build time variable but the YAML only uses it once, to concatenate some text to make up the resource group name.
I then ran dotnet deploy using the same command line as Azure Pipelines runs, but the web.config it writes into the final publish output folder doesn't contain the offending line either.
It was only a few weeks ago I rebuilt and redeployed all my Azure resources. It was all clean, and it's all scripted.
Where on Earth has it come from??!
I'm worried that if I remove it, one day, it'll magically just reappear. It smells very much like someone at Microsoft thought this automagic was a good idea.
Mind you, I've tried to remove it using the App Service Editor and Kudu but I'm not allowed!!
Your app is currently in read only mode because you are running from a package file. To make any changes, please update the content in your zip file and WEBSITE_RUN_FROM_PACKAGE app setting.
So if I'm not setting it, and I'm not allowed to change it, what do I do??
Update 1
I've downloaded the artifacts from Pipelines and the web.config has the setting in place.
The command run, according to the Pipelines log, was this.
dotnet publish --configuration Release --output D:\a\1\s/dotnet-publish-output
But when I run that myself, on my machine, it does not meddle with my web.config.

Answer 1

Wow. So whilst on the school run, it occurred to me that the value that the dotnet command writes into the web.config is correct. How does it know?
The only way it can know is from that environment variable I'm setting in Azure Pipelines and using in my YAML file azureResourceGroup: tz-$(environmentName).
And when I run it on my dev machine vs. running on the Azure build server, that environment variable is not set.
So I set environmentName in the environment on my dev machine before running dotnet publish and, hey presto! It screws up my web.config by adding an environment variable! Amazing.
> $env:environmentName = "undocumented-feature"
> dotnet publish --configuration Release --output C:\DATA\Published
...
> cat C:\DATA\Published\web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\MyWebsiteYeah.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="undocumented-feature" />
</environmentVariables>
</aspNetCore>
<security>
<requestFiltering>
<requestLimits maxUrl="32768" maxQueryString="262144"/>
</requestFiltering>
</security>
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: 3E05D228-D9AF-4782-8E33-1F0E69992750-->
Isn't that dreadful.
So I solved the whole problem with my websites ignoring the variables set in the portal by changing the variable name in Pipelines to hostEnvironmentName.