Structured variable replacment not working for XML

[wbagdon1 (Wbagdon)]

Octopus Server 2020.4.6

I’m attempting to use the structured variable replacement feature to replace parts of an XML file, but it keeps trying to read the file as JSON

System.Exception: Structured variable replacement failed on file F:\Websites\Development\Umbraco\0.1.0.35_1\config\uSync8.config. The file could not be parsed as Json: Unexpected character encountered while parsing value: <. Path '', line 0, position 0. See verbose logs for more details. 
   at Calamari.Common.Features.StructuredVariables.StructuredConfigVariablesService.DoReplacement(String filePath, IVariables variables, IFileFormatVariableReplacer[] replacersToTry) 
   at Calamari.Common.Features.StructuredVariables.StructuredConfigVariablesService.ReplaceVariables(RunningDeployment deployment) 
   at Calamari.Deployment.Conventions.StructuredConfigurationVariablesConvention.Install(RunningDeployment deployment) 
   at Calamari.Deployment.ConventionProcessor.RunInstallConventions() 
   at Calamari.Deployment.ConventionProcessor.RunConventions() 
Running rollback conventions... 

The file looks like this:

<?xml version="1.0" encoding="utf-8"?>
<uSync>
  <BackOffice>
    <Folder>~/uSync/v8/</Folder>
    <FlatFolders>True</FlatFolders>
    <ImportAtStartup>False</ImportAtStartup>
    <ExportAtStartup>False</ExportAtStartup>
    <ExportOnSave>True</ExportOnSave>
    <UseGuidFilenames>False</UseGuidFilenames>
    <BatchSave>False</BatchSave>
...

I’ve setup the variable /uSync/BackOffice/Folder

The documentation (https://octopus.com/docs/deployment-process/configuration-features/structured-configuration-variables-feature) states:
“If the file extension is not recognized (for example, a file with a config file extension), Octopus will try to parse the files using each of the supported formats until a matching format is found.”
It only appears to be looking for JSON.

[Justin_Walsh]

Hi @wbagdon1!

This was identified as a shortcoming in our new Structured Configuration feature - thankfully, we did release a fix for this exact issue in 2020.5.3, so that it will now examine the file’s contents to properly determine the file type, rather than the behavior you’re experiencing.

I hope this helps, and please let us know if you have any further questions!

[wbagdon1 (Wbagdon)]

Thanks, it would be nice to include that info in the docs or if it could be backported to 2020.4.x

[Justin_Walsh]

Thanks for the feedback, I’ll pass that back to the team and see if we can get it backported into 2020.4. Owing to the holidays coming up in the next couple of days, it is unlikely that this will happen until the new year, but I’ll definitely pass it through.

Have a great holiday season!

[wbagdon1 (Wbagdon)]

You as well, thanks again!