英文:
How are Azure Dev Ops variables related to dotnet publish (or msbuild)?
问题
我们的.NET Core Web项目不包含web.config文件。我们知道，如果它不存在，dotnet publish将创建该文件。
但是，我们觉得奇怪的是，即使在dotnet/DotNetCoreCLI@2命令的发布选项中没有使用p:EnvironmentName参数进行指定，ASPNETCORE_ENVIRONMENT环境变量也被设置在新的web.config中。
我们发现在ADO中有一个变量组，其中定义了EnvironmentName变量，发布隐式使用了这个变量。
我不清楚这个变量是如何传递给发布命令的。我发现ADO变量会加载为环境变量。但是发布是否会查找与环境变量匹配的环境变量以用作默认值呢？在“Transform web.config”文档中有这些有点模糊的引用：
它提到了一个构建“属性”，但演示了一个变量语法。
这个EnvironmentName参数是如何从这个ADO变量中推断出来的？
英文:
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.
We discovered that we had a variable group in ADO with an EnvironmentName variable defined and publish was implicitly using this variable.
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:
It references a build "property" but demonstrates a variable syntax.
How is this EnvironmentName parameter being inferred from this ADO variable?
答案1
得分: 0
以下是翻译好的部分：
在Azure DevOps管道中，预定义的系统变量和自定义用户变量都被设置为环境变量。任务（例如DotNetCoreCLI、MSBuild、PowerShell）在这个环境中运行。
dotnet publish命令使用msbuild来执行发布操作。
MSBuild将所有环境变量映射到MSBuild属性中（请参见MSBuild文档中的"在构建中使用环境变量"）。
因此，总结一下：
- Azure DevOps变量组定义了一个名为
EnvironmentName的变量。 - 将该变量组添加到管道中，从而创建一个名为
EnvironmentName的管道变量。 - 管道变量被设置为环境变量。
- 环境变量被设置为MSBuild属性。
- web.config的转换逻辑查找并使用名为
EnvironmentName的属性。
变量组可以轻松用于设置和控制MSBuild，而无需在命令行上明确设置属性。这很方便，除非出现意外的名称冲突。
作为一种实践，您可能希望采用一种用于命名非覆盖用户变量的前缀，以减少名称冲突的机会。
关于语法的一点说明：在MSBuild中，属性引用是$(EnvironmentName)，在管道定义（YAML和其他方式）中，变量替换也是$(EnvironmentName)。web.config转换的文档讨论的是MSBuild属性，而不是管道变量替换。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论