WIX / MSI - возможно ли сделать пакет, который оставляет файлы, которые существовали до установки при удалении

Question

Я использую WIX для создания MSI, которые устанавливают стандартные файлы (без exe, com, DLL и т. Д.).На некоторых компьютерах пользователей некоторые файлы в MSI могут уже существовать.Во время установки это не проблема, поскольку MSI автоматически обновляет файлы более старых версий и т. Д. Однако во время удаления я столкнулся с проблемой.

Проще всего объяснить на примере:
файл Джо Блоггса "B "на своем компьютере.Этот файл не был установлен пакетом MSI и не отслеживается системой Microsoft Installer в любом случае.Это обычный файл на компьютере.

Джо Блоггс скачивает и устанавливает мой пакет, который содержит «файл A», «файл B» и «файл C».Когда он устанавливает мой пакет, система установщика Microsoft проверяет «файл B» и устанавливает, что он идентичен «файлу B» в моем пакете.Поэтому он не заменяет «файл B», но помечает компонент MSI, частью которого является файл B. Как установлено.

Джо Блоггс решает, что ему не нравится мое программное обеспечение, поэтому удаляет мой пакет.Когда он делает это, все 3 файла удаляются, несмотря на «файл B», существовавший до того, как мой пакет был установлен.Мои исследования показали, что это связано с тем, что компонент, содержащий «файл B», помечен как установленный.Поэтому, когда вы удаляете пакет, он удаляет «файл B.».

Это все немного технически, но, надеюсь, есть эксперт по WIX / MSi, который знает решение.*

Джим

Answer 1

Если файлы могут уже существовать на отметке машины Component/@SharedDllRefCount="yes"

Установщик Windows автоматически обновит счетчик ссылок, если обнаружит, что файлы уже существуют.

Answer 2

Это известная «проблема» при использовании MSI, и обычно она вызвана неверной стратегией развертывания .Отсутствие подсчета ссылок на самом деле является лишь признаком подверженного ошибкам подхода развертывания.

Практически ни в коем случае ваш установщик не должен вмешиваться в файлы, которые существуют или могут существовать до запуска вашей установки,Это включает в себя файлы, которые вы установили самостоятельно, ссылки на которые подсчитаны другими вашими установщиками!Подумайте, сплоченность и связь, только один установщик должен иметь дело с каждым файлом.

Это общее правило, как правило, вызывает ответ в виде "наш случай особенный".Поверь мне, это не так.Приложение должно использовать свою собственную папку установки в разделе «Program Files», свою собственную папку в пользовательских настройках и свою собственную папку в общих настройках.Он не должен никогда заменять или обновлять общие файлы, такие как пользовательские словари, списки исключений и т. П.

Часто такой подход заключается в том, чтобы упростить "разработку для разработчиков", когда файлам конфигурации требуются значения по умолчанию дляприложение для работы.Совершенно неприемлемо.Само приложение может обращаться к общим файлам, даже обновлять их, если у него есть доступ, но оно может , а не заменить весь файл «настройками по умолчанию» или удалить весь файл при удалении. Приложение несет ответственность за создание работающей среды в отсутствие базовых файлов конфигурации. Затем файлы должны быть сгенерированы из внутренних значений по умолчанию приложений или скопированы из файлов по умолчанию только для чтения, размещенных в другом месте.

Если вы обмениваетесь файлами конфигурации между различными установщиками, я бы развернул их с помощью модуля слияния или просто установил компонент (ы), которые содержат файл (ы), на " shared " и " постоянный"и" никогда не заменять, если он уже существует".Это должно быть «простым решением» описанного вами симптома, даже если вы не следуете рекомендациям по развертыванию, которые я рекомендую выше.

Answer 3

Обычно это делается с помощью резервного копирования и восстановления пользовательских действий.

По сути, вы пишете пользовательское действие, которое может копировать некоторые файлы на основе параметров, которые он получает.Затем вы можете использовать это настраиваемое действие дважды в установщике:

• один раз во время установки, чтобы скопировать исходный файл в папку резервной копии (обычно временные данные или данные приложения)
• один раз во время удаления вскопируйте файл резервной копии обратно в исходное местоположение

Answer 4

Позвольте мне попытаться добавить лучший ответ, чем тот, который я написал ранее. Кажется, я не правильно прочитал вопрос. Я постараюсь разбить это на несколько вариантов:

1. Возможно установить файлы с помощью установщика Windows, которые вообще не отслеживаются подсчетом ссылок. Другими словами, они никогда не удаляются. Вы делаете это путем , исключая GUID компонента, содержащий файл .
2. Однако, по моему мнению, файлы, которые не отслеживаются MSI, как это, на самом деле являются файлами данных, и с ними не следует обращаться обычным образом. Вместо этого вы можете установить их только для чтения в общую папку, например, Program Files, а затем приложение сможет скопировать их в папку данных каждого пользователя. Тогда MSI на них не ссылается, и ничто их не коснется. Более подробное обсуждение этой темы можно найти здесь: http://forum.installsite.net/index.php?showtopic=21552
3. saschabeaumont Component / @ SharedDllRefCount = "yes" подход также должен работать (я не проверял). Этот параметр делает для увеличения счетчика ссылок SharedDll старого стиля в реестре ( HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ SharedDLLs ). Как таковая, это не справочная функция MSI, и я бы не стал слишком полагаться на нее лично. Подсчет ссылок MSI выполняется гораздо более сложным образом в HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Installer и HKCR \ Installer среди других мест. Ничего не трогайте здесь напрямую!

Хорошее практическое правило с компонентом MSI: когда вы определяете путь к ключу (абсолютный путь в реестре или на диске) для компонента, установщик Windows считает, что он "владеет путем к ключу" "и будет ссылаться считать это. Если ref-count равен 1, он удаляет путь ключа и все остальное, что было в компоненте при удалении.

Answer 5

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

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLS\<your dll name> значение после того, как MSI закончила его создание, во время удаления MSI увидит, что файл все еще используется, и не удалит его. Это довольно забавно, но это сработает.

Или вы можете создать резервную копию файлов в другом месте, а при удалении скопировать их обратно.