I was wondering if there is anyway to control the order that configuration transforms, configuration variables and substitutions are applied during a deployment process?
The reason I ask is that I was trying to maintain a domain for a WCF endpoint using a variable in octopus, while also keeping the setting in the base web.config untouched.
So something like:
web.config -> endpoint address set and checked in for local development
web.Release.config -> xml transform to update endpoint with #{Domain} variable in the address
Domain variable configured in octopus
The variable substitution is run after the xml transform, so the web.config ends up with #{Domain}. For now I’ve reverted to having the domain set in the appropriate transform files.
If I understand how variables work correctly, I would need the #{Domain} token in my web.config file if I was using the web.config file as a variable substitution target. This would interfere with local development since the setting would be invalid on dev’s PCs when they checked-out fresh source code (i.e when hitting F5 it wouldn’t be a valid URL).
By placing the variable substitution in the web.Release.config transform file I could avoid this problem, but only if the transform was run after the substitution.
For now I’m happy to use other methods and in the future will probably refactor the setting so that it sits in appSettings.
Sorry - just realized - if you put the #{Domain} value into your transform file, it will be transformed into Web.config as-is, and that’s where the substitution will be performed.
The problem with running transformations first is that the process will need to list all of the different transforms used in all environments, which is a bit awkward.
Does it work for you using the current order, if the substitution is performed on the target file?
Looking into this some more I think changing the order makes sense, but given the probability of breaking existing processes we’ll have to consider this carefully.
I think the problem you had was related to .Release.config file name convention usage, which affects the config file on every release build and may affect dev process (Although developers can/should compile is as Debug).
We are using pretty same setup (on 2.3.3) and have no problem at all.
In the solution Web.config file includes values matching local dev environment. Also, there is Web.deploy.config file that has only transformation directives. Those transformations changes several keys into Octopus variables (i.e. domain url etc).
Web.deploy.config file not used in dev process and doesn’t affects it at all, its transformation executed only by octopus process when we are deploying the build.
So, the fact that substitution happened after transform was not causing us any trouble. Hope, this flow order change will not affect us also.
We are using the same solution you described in your comment and our build is broken since this feature was released with version 2.4.5.
Have you tried to install the octopus since?
We are running with 2.5.11 actually and there is no problem.
Actually build process is not related to Octopus version but rather to octopack version (if you using it). Any way, our .deploy.config files are specified as “content” file in project and doesn’t affect build at all, it used later on at deployment stage by Octopus.
what Ive found is that you have to manually specify the transform file (eg web.release.config or web.deploy.config) in the “target files for substitution” section. so what then happens is that your web.release.config file is substituted first (and now contains xdt transforms to the actual values for this environment rather than the #{OctopusVariables} and then when the transformation is processed (last) it does transform the web.config file to the values you want. It’s a bit clunky and I agree that the transformation should be processed first THEN the variable substitution on the resulting web.config file, but at least this does work
In summary:
Manually specify the name of the transformation file in the “fiiles for substitution” section (since by default octopus only transforms web.config/app.config)
Just one note - you need to select two features: “Configuration transforms” and “Substitute variables in files” to make this setup work.
In “transforms” section specify the extension of the files with transform directives WITHOUT asterisk sign, in the “substitute” section specify the extension of the configuration files WITH asterisk (as pattern) - see attached example.
Thanx a lot for the input.
We ended up changing our build steps to run variable substitutions and transforms as you suggested arhipus.
Before the release 2.4.5 this was not needed and we run variable substitutions directly against the web.config file due to the fact that variable substitutions were executed after the config transformation, but ok, as you put it rgribble - “It’s a bit clunky … but at least this does work”
Hello, i have same issue on version 2.6.5.1010
My configuration screen (untitled.png) is below…
Configuration file name is “Castle.Application.config”
Developers should debug with current value on configuration after checkout.
We created “Castle.Application.Test.config” for transform.
With transform we change values into like #{SampleBusinessConfigKey}
For last we declare a variable in octopus with named “SampleBusinessConfigKey” and with value.
We need to like this because our DevOps is deciding configuration values not us.
The result is below “Untitled2.jpg”, as it seems substitute doing first so transform is changing values into #{SampleBusinessConfigKey} variable definitions and without subtitutite its broken.
