Octopus transformation of blank or application settings is incorrect

Legacy Uncategorised
1

I’m running into what appears to be a bug with how Octopus is transforming application settings that are being set to blank values

In my web.config file I have a couple of settings that I need to set to a blank string for certain environments. I’ve setup Octopus to include variables with those names and Octopus is transforming those variables with a blank value according to the log, but what I’m I’m seeing in my web.config file appears to be incorrectly transformed.

What Octopus is writing to the file:

  <setting name="Blah" serializeAs="String">
    <value>
    </value>
  </setting>

Here is what Octopus is putting into the log when applying this setting:
Setting //[local-name()=‘applicationSettings’]//[local-name()=‘setting’][@name=‘Blah’] to ‘’

What I’m getting when I serialize this into a properties object is a string that looks like this "\r\n ". I can call String.IsNullOrEmpty on the property and it returns false.

What I would expect to get in this situation is XML that looks like this:

        <setting name="Blah" serializeAs="String">
          <value></value>
        </setting>

OR

        <setting name="Blah" serializeAs="String">
          <value/>
        </setting>

Which serializes into a properties object as an empty string: “” and String.IsNullOrEmpty returns true.

I’m running Octopus 2.5.7.384

Thanks.

-Joe

2

Hi Joe,

Thanks for getting in touch! The behaviour you have reported does look incorrect, sorry about the trouble caused.
I have reported this bug which you can track in GitHub here: https://github.com/OctopusDeploy/Issues/issues/1179

Vanessa

3

Hi Joe,

I’ve been attempting to replicate this issue you are experiencing, but I am unable to. When I set the value of the setting to blank I get:

    <setting name="Blah">
      <value></value>
    </setting>

And in the logs I see:

Setting //*[local-name()='applicationSettings']//*[local-name()='setting'][@name='Blah'] to ''

If you could send us the .config files including the transform file (or just the sections causing the issue) so that I can see if I am doing something different to what you are doing.

Henrik

4

Here is the log entry from Octopus on what exactly it’s transforming:

Setting //*[local-name()='applicationSettings']//*[local-name()='setting'][@name='LocalDbCxnStrOverride'] to ''

Here is a reduced down version of the Config file that I’m having Octopus set ApplicationSettings in. This is the way it is when it’s packaged and uploaded to my nuget feed for Octopus.

<configuration>
  <applicationSettings>
    <Test.Settings>
      <setting name="Blah" serializeAs="String">
        <value />
     </setting>
</applicationSettings>
</configuration>

In Octopus I have a variable on the project that is called “Blah” with no scoping and no value entered. I’m not using any Configuration Transforms, I relying on the Configuration variables to update the transforms for me.

Let me know if there is other information I can provide that would be helpful.

Thanks.

-Joe

5

Is the information I provided helping the problem get reproduced? Is there anything else you need?

Thanks.

-Joe

6

Hi Joe,

I updated my config file to look like the excerpt you posted below but have still been unable to reproduce this issue in my environment.

In the logs, do you see this log entry Setting //*[local-name()='applicationSettings']//*[local-name()='setting'][@name='LocalDbCxnStrOverride'] to '' for the Blah setting as well, or it is not present?

Henrik

7

Hi Henrik,

I was trying to put together a test project for you with a test package to better demonstrate the behavior that I’m seeing and while doing that I noticed that I too couldn’t replicate the behavior.

After digging into it, it looks like Octopus is correctly transforming the web.config file and setting those values correctly, but a subsequent powershell script I call to transform some additional settings is screwing up the blank settings that Octopus has put in place!

I don’t think there is a bug in Octopus after all, my own powershell script seems to be the culprit.

Sorry to waste your time on this issue! I’ll be a little more diligent in my research next time.

Thanks.

-Joe

8

Hi Joe,

No problems at all, great to hear that you found what was causing this issue for you!

Henrik