Azure substitution not working correctly

Hello.
We have been using Octopus for our deployments to Azure for a while.
Today we added some new variables we wanted to be substituted in our .cscfg files.
However some of these variables are not picked up by the build. The log output is as follows:

2014-03-28 07:38:33.0953 INFO Beginning deployment…
2014-03-28 07:38:35.4153 INFO Update ServiceConfiguration.Cloud.cscfg
2014-03-28 07:38:39.9156 INFO Updating setting for role Project: ConnectionString = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: ConfigurationService = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: CacheEndpointIdentifier = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: CachePrimaryAuthorizationToken = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: CacheSecondaryAuthorizationToken = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: ReplyUrl = omitted
2014-03-28 07:38:39.9186 INFO Updating setting for role Project: SubscriptionId = omitted
2014-03-28 07:38:39.9506 INFO Upload ServicePackage.Cloud.cspkg

Among these ones SubscriptionId is a new one. However at the same time we added “ActiveDirectory”, “AdApplicationPassword” and "AdApplicationClientId"
They were present in the Variables section for the release, and added to the .cscfg file in question.

You would think that all of them would get picked up.
However I tried deleting the “ActiveDirectory” one and typed it in by hand and saved, created a new release, and redeployed. And now it did replace the “ActiveDirectory” values as well.
I am suspecting there might be some encoding issue here? The spelling was identical and many new releases have been created, so if it was just a matter of outdated variables they should have been picked up by now.
The variables were copy/pasted into octopus from our share site, where the values have been written by one of our indian consultants, and we have had issues before in other products where the encoding on their computers makes for very strange issues in software. Which is why I suspect encoding.

There is in no way any visual difference in Octopus between how the ActiveDirectory entry looked before I manually entered it and after, and the logs don’t really shed any light on the situation either.
So I can only assume there is a bug lurking.

Octopus version 2.3.3.1369

Update:
It is an encoding issue. Copy/Pasting the text into Notepad++ and changing the encoding to ansi the strings looked like "​ActiveDirectory"
Manually typing in the variable names resolved it.
Would however have been nice if Octopus either fixed this automatically, or showed a warning.

Hi - thanks for the info and the update.

I’m not sure that we can fix it automatically since we need to be fairly permissive about what is a “valid” character in Octopus - many customers use various Unicode chars in these names. If you have a chance to look at the value in a hex editor (if the issue happens again) and let us know what the character values are we might be able to figure something out (e.g. if they’re the Unicode BOM, which given there are three of them is a possibility).

When you copied out the invalid values - did you copy them from the variables screen, or the deployment log?

Thanks again,
Nick