For Web applications
MSBuild knows how to transform the web.config files based on the following settings/properties/parameters (in order)
- Build Configuration
dotnet publish --configuration Release
- Publish profile
dotnet publish --configuration Release /p:PublishProfile=FolderProfile
- Environment
dotnet publish --configuration Release /p:EnvironmentName=Production
- Custom file transform
dotnet publish --configuration Release /p:CustomTransformFileName=custom.transform
I think it's typical for developers to make this happen based on build configuration only, and I believe MSBuild (and dotnet) know how to do this based on the <DependentUpon>Web.config</DependentUpon>
element in the Web.[configuration].config item in the project or build script file.
Azure DevOps Release Pipelines is a little different.
The pipeline wants to transform your web.config after the project has been built/published and doesn't know how to do that if MSBuild (or dotnet) has already made an attempt at it. Thus:
[warning]Unable to apply transformation for the given package. Verify the following.
[warning]1. Whether the Transformation is already applied for the MSBuild generated package during build. If yes, remove the tag for each config in the csproj file and rebuild.
[warning]2. Ensure that the config file and transformation files are present in the same folder inside the package.
The warning text states:
- Remove the
<DependentUpon>
tag for each config in the csproj
- Thus: you need to remove the tag from the csproj to prevent MSBuild from transforming the files
- Or: you need to use the
/p:TransformWebConfigEnabled=False
argument to MSBuild.
(note: I believe it is correct that this can be used w/o removing the dependent upon tag, but I could be wrong)
- Make sure the transform source and target files are in the same folder inside the package.
- There may be several ways to do this. I've chosen to mark the transform source config files as content to force MSBuild to include them in the published package.
Now you need to organize your release pipeline in accordance with the File Transforms and Value Substitutions documentation.
[section]Starting: IIS Web App Deploy
====================================
Task : IIS Web App Deploy
Description : Deploy a website or web application using Web Deploy
Version : 0.0.51
Author : Microsoft Corporation
Help : More information
====================================
...
[command]C:...cttctt.exe s:C:...Web.config t:C:...Web.Release.config d:C:...Web.config pw i
[command]C:...cttctt.exe s:C:...Web.config t:C:...Web.Development.config d:C:...Web.config pw i
XML Transformations applied successfully
...
For Non-Web Applications Needing .config Transformation
Getting your .config files to the release pipeline can happen several ways. Here are two.
Your release should have "access" to the repository as a part of the artifact, which will ensure that the deploy agent downloads the source (not desirable IMHO).
You will need to include the web.[stage].config files as part of your build artifact with a copy task, or a minimatch that picks them up.
Once you have the .config files available to the release pipeline
You can use the File Transform Task or XDT Transform Task to perform the transformation operations.
Option 2 is the route I've gone.
Here is an image of what that task looks like for me.
That task puts the config in the artifact from the build that I can then use in the release pipeline without rebuilding xx times.
Cleanup
If you're in a position where you care to not have the transform files persisting on the agent after the release is complete, then you'll need to add that to your pipeline.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…