I think you can transform any config file in azure devops, not just web.config, using a File Transform Task

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/transforms-variable-substitution?view=azure-devops&tabs=Classic

I've not done this personally, but it looks like this would be the starting point

hth

t

I use the parameters.xml file method (mainly because i am often substituting other things too.)

https://docs.microsoft.com/en-us/aspnet/web-forms/overview/deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-package-deployment

In root of site solution i have a parameters.xml file.

the following snippet for the clientDependency version :

<parameter name="ClientDependency.Version"
         description="Change the ClientDependency Version"
         defaultValue="#{ClientDependency.Version}#"
         tags="">

    <parameterEntry kind="XmlFile"
                scope="ClientDependency\.config$"
                match="/clientDependency/@version" />
</parameter>

When your build Step builds the site it should include a SetParameters.xml file in the artifact zip file.

On your release step, I use the 'replace tokens' task. ( https://github.com/qetza/vsts-replacetokens-task#readme ) to replace the token values in my parameters file.

So the step looks like this :

This means when the azure deploy step runs those variables are replaced in the configured files.

for this example - in the parameters.xml I have called my variable ClientDependency.Version so now on my release setup I can replace this with something with something like a deployment id - so i know its always different each release.

I use : $(Build.BuildID)$(Release.DeploymentID)0

So for the build id and release id are smudged together and an extra 0 is added (so if you really have to you can manually increment the number of the server and know it won't clash with a later release)

build 12 release 41 would set the value to 12410

This might not be the simplest method for just client dependency but it opens up the ability to change things all over the place from one file and variables in your pipeline.

And this is a release time not build time substitution meaning one build can go to different environments.

Thanks for responding guys, I'll have a read through and see if this sorts our issue.

Thanks again for the help.

Cheers

Paul

is working on a reply...