I’m using the “.NET Configuration Transforms” option in my .NET web application deployment step. I am replacing a Web.config appSetting Web.Config.AppUrl (needed for Federation) with a URL that contains a tenant-specific value. I build the variable definition in a common variable, which has been building it using an environment-level variable indicating protocol (http|https). This was working well when I defined the hostname as a common variable based on environment (multi value based on env) and set it in a tenant-level Web..config.
I was using a generic hostname for our QA hosts and that worked for awhile. Now I want to put the specific tenant’s hostname into the web.config. I would like to use a tenant variable (#{Tenant.Web.Hostname}) to build Web.Config.AppUrl.
So I changed the definition of Web.Config.AppUrl to refer to #{Tenant.Web.Hostname}, and added Tenant.Web.Hostname var to a Library variable set that is already used on every Tenant.
I also changed my Web.QA.config file to go from a harcoded name to use the Web.Config.AppUrl value. According to deploy logs, Octopus sees this file and supposedly applies the Web.QA.config transform, but the final Web.config ends up with the string “#{Web.Config.AppUrl}” instead of my common library value. Interestingly, if a tenant-level transform file references this common variable, it is working, bringing in the tenant value.
Are we not permitted to use Tenant vars as a part of common library definitions in an environment-level transform?
How would I achieve this goal of getting the tenant host into my Web.config via transform file (or other means)?
Thanks!!!
Hi Jesse,
Thank you for getting in touch, and great question! Full disclosure off the bat that I am confident I haven’t tested the concept here exactly as you have in your case, so it’s possible I will want to end up looking at a copy of your verbose deployment logs to hopefully get a better understanding of exactly the process here. 
I did do some testing locally and I was able to use tenant variables in a transform file which then was used against a config file that sounds loosely like what you’re doing at least. Going through the motions, I had a thought that perhaps a possible cause of this unexpected behavior in your case might come down to scope specificity.
Is it possible these variable evaluations are not ending up as expected due to variable specificity? E.g. perhaps there’s a matching variable in the project/variable set, that isn’t in the common variable template, which is scoped more specifically? Step, machine, and/or role scoping on a variable will take precedence over a tenant variable.
If that’s not applicable here, it would be worth having a look through the verbose deployment log as mentioned above and hopefully we can spot the issue, or give me more info to reproduce this scenario.
I look forward to getting to the bottom of this issue!
Best regards,
Kenny
Hey Kenny!
Thanks for the swift reply. Those two settings were totally helpful. I was able to see that it was computing the correct value.
However – I had only specified Web..config in the Substitute Variables portion of my deploy step, so it was “applying” The QA.config, but it was not doing var substitution before it applied it. Once I added Web.#{Octopus.Environment.Name}.config to the list of files to process, it changed the configuration as expected.
Thanks for all your help!!!
1 Like
Hey Jesse,
Thanks for following up and letting me know you got this sorted.
Good catch, and sounds like you’re right on the money. In case you’re interested, we have a relevant doc section that lists the order of features in which they’re run (e.g. var substitution before config transformation).
Let me know if you have any questions or concerns at all in the future!
Best regards,
Kenny