Variable with backslash missing in output

[wahabshah]

I have variable $(CPath) with value C:\software
I am trying to patch the following XML's LogFile node

<?xml version="1.0"?><Configuration>
  <Runtime>
<LogFile>C:wnetRCdsfsd</LogFile>
</Configuration>

using Pach Content :
= /WnetConfiguration/Runtime/LogFile => "$(CPath)"
In the output XML, I am getting

<?xml version="1.0"?><Configuration>
  <Runtime>
<LogFile>C:software</LogFile>
</Configuration>

As can be seen, output LogFile node is missing the backslash.

[asiffermann]

Hi @wahabshah and thank you for your report.

Could you upload us the debug logs of the task as mentionned here?
It will help us to investigate where the problem happens :)

We'll try to fix your issue as soon as possible!

[sandorfr]

I'm away for a few days so I'll look into this later this week. However I think I know where this comes from.
Variables are replace by vsts for early bound and by the task for late bound variable. In the both case this is just text replacement without any escaping and this must conflict with JSON escapement.

I think we should find a way to prevent vsts automatic evaluation of variables and then escape variables value before replacement.

A few unit tests around values and escaping and a fix are needed. As usual PR are welcome :)

[wahabshah]

Here is the log for the task with System.Debug set to true.
It is failing as you can see on character next to the backslash

2016-08-22T19:52:58.5066223Z Set workingFolder to default: C:\agent-legacy\tasks\XmlPatch\1.1.1000

2016-08-22T19:52:59.1508799Z ##[debug]agent.workFolder=C:\agent-legacy\_work

2016-08-22T19:52:59.1518803Z ##[debug]loading inputs and endpoints

2016-08-22T19:52:59.1528807Z ##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN

2016-08-22T19:52:59.1538811Z ##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION

2016-08-22T19:52:59.1548815Z ##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION

2016-08-22T19:52:59.1548815Z ##[debug]loading INPUT_JSONPATCHCONTENT

2016-08-22T19:52:59.1548815Z ##[debug]loading INPUT_OUTPUTPATCHFILE

2016-08-22T19:52:59.1558819Z ##[debug]loading INPUT_SYNTAXTYPE

2016-08-22T19:52:59.1558819Z ##[debug]loading INPUT_XMLTARGETFILTERS

2016-08-22T19:52:59.1578827Z ##[debug]loading INPUT_XMLWORKINGDIR

2016-08-22T19:52:59.1578827Z ##[debug]loaded 8

2016-08-22T19:52:59.4299915Z ##[debug]XmlWorkingDir=C:\agent-legacy\_work\3da06a071\WnetPacket\deploy\WnetInstallation\Common

2016-08-22T19:52:59.4299915Z ##[debug]JsonPatchContent==  /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"

2016-08-22T19:52:59.4299915Z ##[debug]OutputPatchFile=true

2016-08-22T19:52:59.4309919Z ##[debug]SyntaxType=slick

2016-08-22T19:52:59.4309919Z ##[debug]XmlTargetFilters=Common_EF.config

2016-08-22T19:52:59.4309919Z ##[debug]Namespaces=null

2016-08-22T19:52:59.4339931Z =  /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"

2016-08-22T19:52:59.4339931Z =  /WnetConfiguration/Runtime/LogFile => "C:\wnetRC"

2016-08-22T19:52:59.4349935Z SyntaxError: Unexpected token w

2016-08-22T19:52:59.4349935Z ##[debug]task result: Failed

2016-08-22T19:52:59.4399955Z ##[error]SyntaxError: Unexpected token w

[sandorfr]

Hi @wahabshah, this is exactly the issue I diagnosed. The bad news is that in this case variable replacement is done by vsts itself and they do not provide a way to retrieve unexpanded input.

So basically we can't know where a variable was located in the string and might need JSON escaping.

The easiest way to fix this would be for you to escape your variable yourself i.e. $(CPath) should be set to C:\\wnetRC

We might consider adding a custom syntax like #(VariableName) which would perform the escaping in the future

[wahabshah]

Thanks @sandorfr
I am using your advice of using double slash in the variable to escape it for the time being. Just checked it and it is working as expected.

[sandorfr]

@wahabshah Considering there won't be any way to do this using native vsts variable suppport, I'll will implement the custom syntax soon. I'll keep you posted when this will be available.