0

Our .net core web project contained no web.config. We are aware of that dotnet publish will create the file if it does not exist.

However, we found it odd that the ASPNETCORE_ENVIRONMENT environment variable was also being set in this new web.config, even when we were NOT specifying it with the p:EnvironmentName parameter in the publish option of the dotnet/DotNetCoreCLI@2 command.

enter image description here

We discovered that we had a variable group in ADO with an EnvironmentName variable defined and publish was implicitly using this variable.

enter image description here

It is not clear to me how this variable is being transfered to the publish command. I did find that ADO variables are loaded as environment variables. But does publish look for environment variables that match environment vars to use as defaults? In a "Transform web.config" documentation there are these somewhat obscure references:

enter image description here

It references a build "property" but demonstrates a variable syntax.

How is this EnvironmentName parameter being inferred from this ADO variable?

b_levitt
  • 7,059
  • 2
  • 41
  • 56

1 Answers1

0

Variables in Azure DevOps pipelines, both predefined system variables and custom user variables, are set as environment variables. Tasks (e.g. DotNetCoreCLI, MSBuild, PowerShell) are run with this environment.

The dotnet publish command uses msbuild to perform the publish.

MSBuild maps all environment variables to MSBuild properties. (See "Use environment variables in a build" in the MSBuild docs.)

So to summarize:

  • The Azure DevOps variable group defines a variable named EnvironmentName.
  • The variable group is added to the pipeline creating a pipeline variable named EnvironmentName.
  • The pipeline variable is set as an environment variable.
  • The environment variable is set as an MSBuild property.
  • The web.config transform logic looks for and uses the property named EnvironmentName

Variable groups can easily be used to set and control MSBuild without explicitly setting properties on the command line. Which is nice unless there is an unintentional name collision.

As a practice you may want to adopt a prefix for naming user variables that are not overrides, to lessen the chances of a name collision.

A note on syntax: In MSBuild a property reference is $(EnvironmentName) and in pipeline definitions (YAML and otherwise) a variable substitution is also $(EnvironmentName). The documentation for the web.config transform is talking about an MSBuild property and not a pipeline variable substitution.

Jonathan Dodds
  • 2,654
  • 1
  • 10
  • 14
  • thank you for the answer and you are confirming what we believed. Is there documentation that indicates msbuild uses env variables as parameters of the same name? – b_levitt Apr 11 '23 at 13:19
  • 1
    Yes. See "[Use environment variables in a build](https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-use-environment-variables-in-a-build?view=vs-2022)" from the MSBuild docs. I added that reference to the answer. – Jonathan Dodds Apr 11 '23 at 13:26