Удалить компонент GUID = ", установленный с помощью WiX

Question

Я испортил мой установщик на основе WiX на нескольких серверах, чтобы он не удалял файлы или компоненты (или даже другие функции) во время удаления. Журнал MSI показывает, что PreviouslyPinned = 1 для всех компонентов, которые не будут удалены.

У меня нет ничего интересного, как использование SharedDll или даже разделяемых компонентов среди разных инсталляторов.

Я думаю, что я отследил его до конкретной версии моего WiX-кода. Я сделал пару глупых вещей. Я (неумышленно) создал неуправляемый компонент с пустым Guid

<Component Id="file.ext" Guid=""> 
    <File .../> 
<Component> 

и я также изменил местоположение файла другого компонента и Id (но не это Guid). Все компоненты, присутствующие в более ранних версиях, показывают, что PreviouslyPinned = 1 и не будут удалены, а новые компоненты добавлены после правильной установки и удаления этой версии.

Как я могу вернуть своего установщика в нормальное состояние и удалить эти ранее закрепленные компоненты?

Answer 1

Windows Installer фактически поддерживает концепцию пустой GUID. Это означает «установить, но не регистрировать компонент»: http://msdn.microsoft.com/en-us/library/aa368007(VS.85).aspx (В записи ComponentId объясняется, что происходит с нулевым GUID).

Я только что протестировал с помощью WIX и, по-видимому, соблюдал пустую запись GUID (т. Е. Никакой указатель не сгенерирован автоматически). Помните 1: правило 1 между абсолютным путем/ключевым путем и GUID:

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

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

Очистка перепутанного подсчета ссылок GUID может быть немного грязной. Я нахожу, что если я могу изменить имя файла, которое эффективно устраняет проблему. Я также создаю новый указатель и, следовательно, разорву ссылку на счетчик старого руководства. Вы также можете переименовать папку установки (что в идеале означает, что все компоненты GUID также должны быть изменены). Концепция таблицы RemoveFile может использоваться для удаления файлов при установке и/или удалении, которые не были зарегистрированы как компоненты (например, сгенерированные файлы).

Answer 2

Изменение идентификатора компонента и использование действительного идентификатора GUID должно сделать все правильно.

Answer 3

Короткий ответ:

Да, используя компоненты MSI без GUIDs является своего рода способ периодического копирования. Скопируйте и забудьте. Конечно, вам нужно добавить одну вещь: удалить все файлы перед каждым переустановкой или удалением (условие «REINSTALL или PATCH или REMOVE») или Major Upgrade. Без этого это не имеет смысла. Вы можете сделать это в пользовательском действии даже с CMD.exe/c RD/S/Q .... (Конечно, пользовательский код более изящный)

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

Еще не пробовал, но я буду: наличие «динамических» компонентов без GUID и обычных компонентов, а затем предоставление патча. Теоретически это должно работать, и это было бы хорошим обходным решением для ряда проблем исправления, возникающих из-за сильно изменяющихся наборов файлов между патчами.

Answer 4

1. Фактически, компоненты без GUID являются реальным методом «динамического связывания файлов», который часто ошибочно воспринимается несколькими инструментами или людьми.

Другие «пути»: 2. Генерация GUID, автоматически является лишь шагом автоматизации (но, конечно, часть каждой хорошей настройки сборки инфраструктуры :-) В моих глазах это не динамически, потому что если вы сделаете это динамически, вы делаете это неправильно:

2a. Генерирование GUID, которые являются полностью случайными каждый раз => неправильный алгоритм

2b. Генерирование GUID только при создании компонента и при внедрении интеллектуального распознавания «diff» для новых ресурсов, которые должны быть упакованы в новый компонент. => Единственный рабочий метод дерева-синхронизации. Но вы можете сделать здесь много ошибок ... Это для экспертов.