How can an element disapare during xslt even if I never specify "Remove" as action?

Question

I have a very strange behaviour with my xslt transformation in one of our web-services.

We have the following section in the web.config file (with other things as well)

<AppSettings>
  <add key="TemporaryUpload.Folder" value="TempUpload\"/>
  <add key="MailClient.SmtpHost" value="" />
  <add key="MailClient.MailEnabled" value="false"/>
</AppSettings>

We then have a web.production.config transformation file which is triggered (can be seen on the transformed web.config for other parts). However we have a problem where one of the rows in the AppSettings section instead of being replaced is removed.

The transformation part looks like the follwing

<AppSettings>
  <add xdt:Locator="Match(key)" xdt:Transform="SetAttributes" key="MailClient.MailEnabled" value="true" />
  <add xdt:Locator="Match(key)" xdt:Transform="SetAttributes" key="MailClient.SmtpHost" value="mailhost.test.se"/>  
</AppSettings>

The first line is replaced accordinly but the second seems to somehow remove the element instead of replacing it. In other words the section in the transformed web.config is like the following

<AppSettings>
  <add key="TemporaryUpload.Folder" value="TempUpload\"/>
  <add key="MailClient.MailEnabled" value="true"/>
</AppSettings>

I have tried to using xdt:Transform="Replace" instead of "SetAttributes" but the effect seem to be the same.

As I have said all the rest of the transformations works as intended its just that single row that for some reason gets deleted instead of transformed.

So if anyone has any clues feel free to enlighten me, as it is at the moment I have to resort of checking the config file and inserting the row if it is missing but I'm worried that there might be other rows missing in the future.

Answer 1

The problem seems have originated by the fact that the default value in the web.config was an empty row. As soon as I replaced the default value with a dummy value instead it all worked as intended.

I can't understand why this would be a fact for different behaviour but apparently it is. So the solution to this problem is NEVER set a default value in a web.config that will be transformed for different build definition to an empty string, always set a dummy value instead.