Принудительный запуск загрузчика WiX Burn, чтобы файлы MSI могли использовать REINSTALLMODE=amus

Question

Так как я не был частью моей компании, когда наш процесс сборки был спроектирован и реализован (и уже несколько лет успешно), я обнаружил, что были сделаны вещи, которые можно рассматривать как "хаки". 'MSI ' пуристы '. Однако, чтобы получить работающий установщик с Visual Studio 2012, я делал все возможное, чтобы имитировать то, что было сделано с .vdproj файлы в Visual Studio 2010. Из множества препятствий, с которыми я столкнулся, этот, кажется, последний, который я не могу устранить.

В рамках нашего процесса сборки с Visual Studio 2010 мы создали наш код и создали Framework MSI на одной виртуальной машине. Затем мы взяли этот MSI Framework и установили его на другую виртуальную машину. После того как фреймворк был установлен, мы создали код нашего продукта и создали из него MSI-продукт. Это создало зависимость продукта от нашей платформы. Это означало, что при установке на клиентском компьютере загрузчик должен сначала установить Framework, а затем продукт. При удалении нашей документации указано, что она обрабатывается через ARP или через командную строку 'msiexec /x {Product.msi/@ProductCode}а потомmsiexec /x {Framework.msi/@ProductCode}".

В то время руководство определило, что ProductCode Для других групп разработчиков это был бы самый простой способ определить, был ли наш продукт установлен на компьютере. Это привело их к решению о том, что им нужно сохранять статичность ProductCode как для платформы, так и для продукта.

Для того, чтобы обрабатывать обновления, они должны были создать ProductTool.exe это было не что иное, как msiexec, завернутый в исполняемый файл, который занял /ProductCode={@ProductCode} аргумент.

Как часть нашего загрузчика, они назвали:

• Предварительные требования для установки ( установщик Windows 4.5,.NET 3.5 с пакетом обновления 1 (SP1), SQL Server 2008 R2 Express, синхронизация 2.1)
• ProductTool.exe (Product.msi - удалить Product.msi)
• ProductTool.exe (Framework.msi - удалить Framework.msi)
• устанавливать Framework.msi
• устанавливать Product.msi

Однако до недавнего времени я не обнаружил, что загрузчик Burn не позволяет REINSTALLMODE=amus, В журналах установки говорится, что он изменяет его на REINSTALLMODE=vomus, По-видимому, чтобы этот вышеупомянутый процесс работал над обновлениями, они должны были установить REINSTALLMODE=amus,

ОБНОВЛЕНИЕ: я наконец-то поговорил с первоначальным разработчиком установщика и узнал, что REINSTALLMODE=amus использовался преднамеренно, чтобы вернуть все версионные файлы (сборки, файлы DLL и т. д.) и не версионные файлы (.config, сценарий SQL и т. д.) в качестве стратегии минимизации рисков и надежности /"самовосстановления".

Сказав все это, возможно ли даже с помощью стандартного приложения начальной загрузки Burn (BA) установить REINSTALLMODE=amus чтобы я мог заставить работать обновления? Файлы MSI имеют набор свойств, но Burn, кажется, переопределяет его.

Answer 1

Нет, это не поддерживается движком Burn сегодня. Burn контролирует REINSTALLMODE очень аккуратно, чтобы правильно обрабатывать обновления и ремонт. С помощью a в REINSTALLMODE далеко от передовой практики и поэтому не поддерживается. Кроме того, не ясно, почему a необходимо в сценарии, который вы описали.