Unfortunately, the deployment runs them in the wrong order:
Transforming 'C:\Octopus\Work\...\web.config' using 'C:\Octopus\Work\...\web.Release.config'.
...
Structured variable replacement succeeded on file C:\Octopus\Work\...\web.Release.config with format Xml
I would need it to first apply the Structured Configuration Variables (replacing an attribute value in web.Release.config) and then run the .NET Configuration Transform (transforming web.config using web.Release.config).
How can I ensure that the Structured Configuration Variables are applied first?
Thanks for getting in touch, and great question. Unfortunately there’s no direct way to change this ordering-convention (outlined in its entirety here), though I imagine there might be a couple of ways to tackle this.
My suggestion will probably end up being to instead target the web.config file in the structured config variables feature. If that itself won’t work for any reason, you might be able to split this package step into two where each would run only one of the two features on it so you can get control over this ordering. Similarly, perhaps disable the transform feature on the package step (keeping structured config variables enabled) and then add this community step template after the package step:
Hi Kenny,
thanks for the very quick response, much appreciated!
I understand that there’s no way to change the order of steps.
Would you elaborate on that a little bit? It would be great if I could modify web.config with the structured config variable feature. The challenge is that I need to add an XML element (specifically, an <environmentVariable> element) to that file.
Here’s an outline how web.config looks in the package:
The deployment should add another <environmentVariable> element (with a value based on an Octopus variable), so that web.config looks like this afterwards:
The challenge is that the element doesn’t exist yet and hence needs to be added.
If it did already exist, we could create a structured config variable /configuration/system.webServer/aspNetCore/environmentVariables/environmentVariable[@name='ASPNETCORE_ENVIRONMENT']/@value to update it accordingly.
But it doesn’t exist, and unfortunately it would be problematic to add it (e.g. with an empty value) because that would have other undesirable side-effects.
Is there a way to add the element with the structured config variable feature?
No worries, so my idea was to target the web.config in the structured variable feature, and I ran through a quick test locally to confirm, which was successful. I am thinking this should work in your case as well, even though the /configuration/system.webServer/aspNetCore/environmentVariables/environmentVariable[@name='ASPNETCORE_ENVIRONMENT']/@value doesn’t exist in the web.config at the start of the deployment.
The transform feature will run before the structured config variable feature, so when it is run it will exist in the web.config as it was previously added via the web.release.config’s transformation (I imagine you have something like this? <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" xdt:Transform="Insert"/>)
I hope that helps, and please let me know if I’m making any incorrect assumptions in any way!