How avoid *.<Environment>.config transformations being deployed on server

Question

I'm using VSTS to deploy at several environments. And as usual, some parameters on config files need to be different depending the environment, hence I will use config transformations to deploy it at the target environment.

Since I want to have the package with both the config and the transform that will be applied later I set the Build Action as Content as such:

<Content Include="App_Config\MyConfig.config" />
<Compile Include="App_Config\MyConfig.prod.config">
  <DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.uat.config">
  <DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.dev.config">
  <DependentUpon>MyConfig.config</DependentUpon>
</Compile>

The package is done correctly and the deploy as well (MyConfig.config has the parameters changed depending on the environment it runs). My problem is that on the server machine I have the MyConfig.*.config files as well.

Looking at the official documentation example note's (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/transforms-variable-substitution?view=vsts#xml-transformation-example) doesn't give anything clear. It's just "msbuild will do it before packaging and azure not" but doesn't explain a way to do it.

Edit: Solution I went with.

Basically I couldn't avoid to keep the artifacts clean, as they are not dependant on the environment. So after all Release pipeline I added a Delete files job (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/utility/delete-files?view=vsts) To remove all configuration files with the following parameters:

Source Folder:
    $(wwwRoot)\

Contents:
    **\*.Debug.config
    **\*.Release.config
    **\*.UAT.config
    **\*.PROD.config

Supereminent

Do you solve this issue with Secure Files? – Izy

Answer 1

First, with XML file transformation, the xx..config file is required. Secondly, the transform will be applied when publish web app to web deploy package or publish to server directly per to the configuration (e.g. Release, Debug).

Regarding web deploy package, there is xx.SetParameters.xml file, which contains the related transformed elements and the value will be applied during deploy. You can update that file before deploy.

Web.config Transformation Syntax for Web Project Deployment Using Visual Studio

Update:

You also can store the files in Secure Files, then copy the file to related folder through Copy file task:

1. Download Secure File task
2. Copy file task (Source folder: $(agent.builddirectory)\..\_temp)

Izy

As I understood, SetParameters.xml is only valid for web.config and only certain values like connectionstrings and such that are usually changed. Also seems to be generated automatically (learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/…). On my case its not on the web.config but a 3rd party configuration file. – Supereminent

The xx.environment.config file is required during deployment, you may remove the file after deployment, on the other hand, you may consider the other ways, such as XML variable transform. – Izy

@Supereminent You can store the files in Secure Files, check the update of my answer. – Izy

Secure files need also the copy file task and remove like the other options. In the end I will do a lot of extra work for keeping artifacts clean. – Supereminent

Solution I went with it was adding a Delete-files job in the end (learn.microsoft.com/en-us/vsts/pipelines/tasks/utility/…) removing all config transforms: ***.Debug.config ***.Release.config ***.Production.config etc etc – Supereminent

@Supereminent Thanks for the hint. This is what I did in the end. In my case, it was a website deployment using Azure DevOps task IIS Web App Deploy with various config files in various folders. So I specified \\$(Agent.MachineName)\sites\$(WebsiteName)\www as the source folder and **/*.Debug*.config, **/*.Development*.config, **/*.Staging*.config and **/*.Production*.config as the line-separated contents. $(WebsiteName) is a variable I have to set in the release pipeline. – Lase

Answer 2

You would probably need to think about creating a post deploy script to clean those files and add it to your release script to run at the end of deployment.

Berkeley