Неправильная работа "Repair" в инсталляции

Пришел баг от тестеров (проверяли перед релизом правильную работу установщика + upgrade с предыдущих версий).
Говорится, что при выполнении "Repair" для инсталляции система становится неработоспособна.
Пытаемся воспроизвести баг - ничего. Идем на стенд, воспроизводим - ничего.... Начинаем думать...

Короче, мытарств было много, забавным оказался результат - по итогу на той машине стенда, где проверялась инсталляция... оказалась неисправна батарейка, питающая CMOS.

Когда компьютер выключали, дата сбивалась, и получалось так, что система устанавливалась (по файловой дате) раньше на несколько лет, чем выпущен билд, который проверялся.

Тут-то и начинал проявляться прискорбный недочет в инсталляции...

Есть в продукте некоторый конфигурационный XML, заготовка которого лежит в CAB'е, и который модифицируется по ходу инсталляции параметрами, характерными для данного компьютера.

Естественно, модификации производятся в зависимости от наличия других компонентов (некоторые приложения можно ставить, а можно и не ставить в зависимости от желания).

Тут-то и сработала лень человеческая - модификация XML-файла была выполнена в составе этих самых компонентов, причем вот таким способом:

    <Component Id="RadarExe" Guid="EB3E97B3-9696-4C97-8BB4-15F1B3C0F256"
               Transitive="yes">
      <File Id="RadarExeFile" Name="radar.exe" DiskId="1"
            KeyPath="yes" Vital="yes" Source="radar.exe" />
      <Shortcut Id="Nr4000iShortcut"
        Advertise="yes" Directory="ProductShortcutDir"
        Name="radar" LongName="$(var.RADAR_SHORTCUT_NAME)"
        WorkingDirectory="RADARRDIR"
        Icon="RadarIcon.ico" IconIndex="0" />
      .....
      <trs:XmlElement id="RadarHttpPath" file="[IBSCONFIGDIR]IBSSvc.xml"
                      path="/serviceConfiguration/object[\[]@name = &apos;HTTP.Server&apos;[\]]/nh:root/nh:handler[\[]@nh:dir = &apos;apps&apos;[\]]"
                      name="nh:handler[\[]@nh:dir = &apos;radar&apos;[\]]" action="overwriteAndRemove">
        <trs:XmlAttributeValue name="name" value="HTTP.FileSystem" />
        <trs:XmlAttributeValue name="module" value="HTTPHandlers.dll" />
        <trs:XmlAttributeValue name="nh:dir" value="radar" />
        <trs:XmlAttributeValue name="nh:description" value="$(var.RADAR_DISPLAY_NAME)" />
        <trs:XmlAttributeValue name="nh:fsDir" value="[RADARDIR]" />
        <trs:XmlAttributeValue name="nh:allowBrowse" value="yes" />
        <trs:XmlAttributeValue name="nh:allowPut" value="yes" />
        <trs:XmlAttributeValue name="nh:allowDelete" value="yes" />
        <trs:XmlAttributeValue name="nh:recursive" value="yes" />
        <trs:XmlAttributeValue name="nh:xslt" value="/xslt/ins.xslt" />
      </trs:XmlElement>
      <trs:XmlAttribute id="RadarPath" file="[IBSCONFIGDIR]IBSSvc.xml"
                        path="/serviceConfiguration/variable[\[]@name = &apos;RADAR_DIR&apos;[\]]"
                        name="value" action="update" value="[RADARDIR]" />
    </Component>

Дальше сценарий развивался примитивно просто:

• Система решает, что раз файл в инсталляции с основой XML новее, чем установленный - его нужно восстанавливать.
  
• Компонент "RadarExe" в обновлении не нуждается (KeyPath поставлен на исполняемый файл), значит и модификацию XML выполнять не нужно (!)
  
• Файл-заготовка перекрывает настроенный.
  
• Описание системы приходит в неконсистентное состояние - все наслаждаются.
  

Самое интересное, что ранее проверка производилась неоднократно - все было OK (модифицировнный файл был новее, Installer его не заменял).
Пока не приключилась такая вот беда....

Понятно, что 98 из 100 пользователей с этим никогда не столкнутся, но вот двоим бы пришлось несладко...

Мораль истории проста - декомпозиция инсталляции на компоненты должна производиться с умом, учитывая случаи Upgrade/Repair, не рассчитывая ни на какие side-эффекты, иначе нас рано или поздно ждут интересные приключения....