В последнее время мы обнаружили, что в нашем скрипте Wix имеется дублирующий компонент GUID. Общий GUID используется для 2 файлов с разными именами, но в том же каталоге. Я сделал некоторые поиски в сети, что это может привести к проблемам позже, но не может найти удовлетворительных решений одной и той же проблемы.Безопасное решение дублирующих GUID компонентов в Wix
Существует ли безопасный способ решения этой проблемы? Благодарю.
Возможно, вы переименовываете файлы и дайте им как новый guid каждый? Это самый безопасный подход - он устраняет все проблемы с подсчетом ссылок. Переименовав файл, вы создаете новый абсолютный путь (путь + имя файла) для каждого файла, а установщик Windows по существу ссылается на абсолютный путь, назначая один guid.
Некоторые дополнительные объяснения концепции. Рекомендуется прочитать, я думаю, что это будет яснее: Change my component GUID in wix?
Примечание: Будьте осторожны, переименование файлов DLL, если вы пишете на C/C++, используя множество delay load.
Я добавлю это как еще один ответ, так как это действительно отличный подход к «решению» проблемы.
Вы можете «решить эту проблему», назначив две новые идентификаторы GUID к файлам и использовать крупное обновление с RemoveExistingProducts начале в InstallExecuteSequence в «отвязать» две версии продукта друг от друга полностью. Эта форма обновления эффективно игнорирует правила компонентов установщика Windows и устанавливает обновление, как если бы старая версия не существовала. Многие компании стандартизируют этот сценарий обновления, хотя он и неэффективен, и медленен, поскольку устраняет большинство проблем, возникающих в результате ссылки на компоненты.
Важное эмпирическое правило: Никакое незначительное обновление или патч нельзя использовать, если вы неправильно выполняете ссылки на компоненты. Я думаю, большинство пользователей Wix это знают.
(Когда два файла совместно используют руководство, технически возможно просто предоставить одному из файлов новый указатель, но я никогда не делаю этого, чтобы избежать повторного поиска старых проблем. В частности, старинный подсчет ссылок устаревшего стиля может заканчиваться интерферированием :. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs Этот флаг записывается, если Wix component имеет msidbComponentAttributesSharedDllRefCount набор битов):
Это ссылка считая от лица установщика Windows, и она используется Windows Installer, тоже для того, чтобы «общаться» с устаревшими установщиками стиля, которые иначе могли бы просто удалять файлы, которые ссылаются на W indows Installer.
Я не устанавливаю этот флаг для любых файлов, которые я не устанавливаю в общие местоположения, и считаю, что это хороший подход. Installshield используется для установки этого общего свойства dll для всех компонентов, и это приводит к тому, что многие удаленные файлы остаются в процессе удаления. Другими словами: включите этот флаг только в том случае, если вы устанавливаете подлинно разделяемое местоположение, поскольку флаг, как правило, представляет большую проблему, чем решение.
Если вы делитесь файлами между вашими собственными приложениями и не нуждаетесь в файлах, доступных для сторонних приложений, просто установите их в ProgramFiles и поделитесь ими через файлы Wix include.
Спасибо за ваш ответ! – whywhywhy
@ Glytzkof спасибо за быстрый ответ, мы попробуем этот подход! – whywhywhy
Также обратите внимание, что [** вы можете оставить много атрибутов источника из вашего XML-файла Wix **] (http://stackoverflow.com/a/24769965/129130) и полагаться на значения по умолчанию Wix вместо жестких значений кодирования. –
Просто из любопытства, если это был файл .net, который нельзя переименовать, как мы это сделаем? – whywhywhy