Объединить существующий файл конфигурации в Wix

В настоящее время я делаю это с помощью комбинации настраиваемого действия и XmlConfig.

Настраиваемое действие запускается после CostFinalize и считывает текущие значения из файлов конфигурации и сохраняет их в общедоступных свойствах.

  string configFile = Path.Combine(session["INSTALLLOCATION"], "app.exe.config");
  ExeConfigurationFileMap map = new ExeConfigurationFileMap();
  map.ExeConfigFilename = configFile;
  Configuration config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
  session["OLD_PRESERVEDVALUE"] = config.AppSettings.Settings["PreservedValue"].Value;

то у меня есть запись XmlConfig, как показано ниже, которая устанавливает сохраненные значения из общедоступных свойств:

   <Component Id="RestoreOldPreservedValue" Guid="<GUID>" >
   <Condition>OLD_PRESERVEDVALUE</Condition>
   <CreateFolder/>
   <util:XmlConfig
       Id='RestoreOldPreservedValue'
       Action='create'
       On='install'
       Node='value'
          ElementPath='/configuration/applicationSettings/app.Properties.Settings/setting[\[]@name="PreservedValue"[\]]/value'
            File='[#app.exe.config]'
            Value='[OLD_PRESERVEDVALUE]'>
        </util:XmlConfig>
     </Component>

Моя следующая итерация будет заключаться в том, чтобы настраиваемое действие напрямую создавало записи в таблице XmlConfig.

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

Короче говоря, это огромная слабость установщика Windows. Изначально MSI не поддерживает операции XML. По сути, установщик Windows обрабатывает файлы атомарно, тогда как XML-файл в некотором смысле похож на целый куст реестра.

WiX добавляет возможности преобразования XML для решения первой проблемы, но вторую проблему решить невозможно. У вас должна быть копия исходного XML, текущего XML и предлагаемого XML, а затем у вас должны быть бизнес-правила, чтобы знать, что объединять, а что не объединять.

Во-первых, чтобы избежать этой проблемы, я лично предлагаю иметь 2 файла XML. Один установлен и полностью принадлежит установщику (stock.xml), а другой не задействован установщиком и принадлежит приложению (override.xml). Затем в вашем XML-ридере сделайте так, чтобы содержимое override.xml имело приоритет над содержимым stock.xml. Таким образом, установщик всегда может делать то, что умеет лучше всего) устанавливать файлы без сложной обработки данных.