Substitution variable in config file


how can i replace these values pointed in picture in Octopus Deploy with "Structured configuration variables
"

Hi @muhammad.sannan1

Welcome to the forum and thanks for your question!

Can you show what specific values/attributes you are trying to update in the XML, and what you have tried so far, If you could provide screenshots of the variables, the use of the Structured configuration variables feature in a step in octopus and the resulting task log that be great.

Please feel free to redact anything sensitive from screenshots or logs

Best,

I’m trying to update value of internalLogLevel and fileName variable (pointed in screenshot with red).
so far i’ve done following steps:
(1) given the name of the file in Structured configuration variables in which i want to change variables


(2) Tried to configure variable name but didn’t help
variable name given in screenshot below is : /nlog[@internalLogLevel=‘Info’]/@internalLogLevel

Hi @muhammad.sannan1

Thanks for that additional info.

There are probably two causes for this issue:

  1. Ensure the path to the config file in the Structured Configuration variables future (within the step) is relative to the package contents. If the nlog.config file is in the root of the package then it should look something like this: **/nlog.config

  1. The variables need to be qualified with any namespaces. Since the NLog example you provided has a root namespace of xmlns="http://www.nlog-project.org/schemas/NLog.xsd" you need to handle this. I chose to use a wildcard as described in our documentation. I therefore went with the following variable declarations

For the internal log level, the variable name is:

/*:nlog/@internalLogLevel

For the path to the file, the name is:

/*:nlog/*:targets/*:target[@name="allfile"]/@fileName

This substituted the values in my sample.

I hope that helps!

Best,

I’ve just checked and it’s working fine. Thanks @mark.harrison

Awesome, that’s great to hear!

Hi Mark,

I experienced similar issue when resetting the mode value from on to off using Octopus Substitute Variables feature. I tried both variables, but no luck. Can you please help? Thanks in advance.

/:configuration/:‘system.web’/:customErros]/@mode /:configuration/:system.web/:customErros]/@mode

image

Regads,

Robert

Hi Robert,

Thanks for getting in touch, and welcome! I’ll jump in quickly for Mark as he’s currently offline as part of our UK-based team. :slight_smile:

It looks like your issue likely comes down to a typo in the variable name, specifically at this spot: :customErros]. I mimicked this Web.config file, and tweaked the variable name and it substituted successfully via the Structured Configuration Variables feature with the following modified variable name:

/*:configuration/*:system.web/*:customErrors/@mode

Let us know if that gets it working!

Best regards,

Kenny

Hi Mark,

Thank you for that. Yes, it was typo. I tried to set the variable as what you suggested, but still no luck.

The path of the Target file I tried was F:/Octopus/Applications/SiteTRAX - SCG Az/**/Web.config and **/Web.config, but the customeErrrors mode is still On.

Any suggestions? Thanks in advance.

Regards,

Robert

Hi Robert,

Thanks for following up! My apologies for the confusion. Your screenshot is showing use of the Substitute Variables in Templates feature, which will find any variable names in the target files via the syntax #{VariableName} and substitute it with the values of matching variable names as defined in your Octopus project.

The syntax /*:configuration/*:system.web/*:customErrors/@mode is used on the Structured Configuration Variables feature which is a bit different.

I imagine if you add the Structured Configuration Variables feature into this package step and specify this same path and Web.config value, that should then work. :slight_smile:

Please let us know how you go!

Best regards,

Kenny

Hi Kenneth,

It works using Structured Configuration Variables feature. Much appreciate.

Regards,

Robert

Hi Robert,

Awesome to hear! Thanks for confirming. Let us know if you come across any other questions or concerns in the future. :slight_smile:

Best regards,

Kenny