Как осуществить обновление установщика WiX?

Кажется, этот вопрос намного популярнее, чем я думал

да, изучение WiX похоже на попытку разгадать непонятные заклинания, которые кто-то решил, что «имеет смысл» выполнить простое действие. Вроде как UNIX.

Хм, я подозреваю, что мне не следует использовать этот конкретный GUID в «Upgrade Id =», но мне придется сопоставить его с чем-то другим. Но что?

Также вам, возможно, придется настроить UpgradeVersion Min и max - например, Если ваша текущая версия меньше 1.0

Кроме того, что именно делает «Изменить идентификатор продукта на *»? Создает ли он каждый раз новый идентификатор продукта? Каковы последствия того, что у вашего продукта больше нет фиксированного идентификатора? - это звучит как излишество.

@Anthony - да, использование * приведет к тому, что каждый раз будет генерироваться новый идентификатор продукта. Я обнаружил, что для работы «автоматического обновления» мне нужен новый идентификатор продукта для каждой версии, и это самый простой способ сделать это.

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

@Antony, @Dror Helper: Я почти уверен, что вам не следует использовать здесь «*» для генерации нового GUID. Идентификатор GUID внутри (Upgrade Id = "") должен быть жестко запрограммирован и исправлен, и он должен соответствовать идентификатору GUID в вашем атрибуте (Product UpgradeCode = "").

Под этим я подразумеваю, что не используйте "*" в идентификаторе обновления, но, конечно, используйте его в идентификаторе продукта, как задумал Dror.

обратите внимание, что это удалит установленную версию Любые, даже если она новее, чем та, которую вы пытаетесь установить.

Я думаю, вам, вероятно, следует отредактировать свой пример, чтобы НЕ иметь фактического GUID. Я уверен, что люди скопируют и вставят это и будут использовать дословно. Может быть, использовать "ВАШ-ПРОДУКТ-UPGRADECODE-GUID-ЗДЕСЬ"?

В вашем примере есть ошибка. ProductVersion от MSI поддерживает только три поля версии; поэтому четвертое поле вообще не будет сравниваться. См. Примечание под VersionMin и VersionMax в msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx

Для wix2 идентификатор продукта должен быть "????????-????-????-????-????????????" вместо "*".

Хотя обновление, похоже, работает с использованием описанного выше метода, в разделе «Установка и удаление программ» я все еще вижу старую версию (и, конечно же, новую). Есть идеи, почему это происходит и как я действительно могу удалить старую версию?

При использовании этой техники мне все еще нужно менять UpgradeCode между выпусками?

Это тоже помогло мне, оказалось, что ПРЕДЫДУЩАЯ УСТАНОВЛЕННАЯ ВЕРСИЯ действительно важна, хотя, похоже, ничто не использует это свойство ...

Я сделал именно то, что было предложено, но у меня это не работает. Если я запустил свою новую установку, она просто проигнорирует существующую установку и установит новую копию. Что мне может не хватать?

Кажется, у меня нет элемента InstallExecuteSequence ... (почесывая голову).

@jpierson Вы уверены, что размещаете InstallExecuteSequence в правильном родительском элементе? Я сделал эту ошибку уже несколько раз

Почему нет элемента DontCareJustCopyTheFiles?

@DrorHelper Можно ли удалить (деинсталлировать) более одного продукта с помощью wix во время установки msi, созданного wix. Пожалуйста, ознакомьтесь с моим вопросом SO и направьте меня stackoverflow.com/questions/26863294/…

Я не уверен, я давно не работал с WIX - я думаю, вам следует написать вопрос вместо комментария, чтобы другие пользователи могли вам помочь.

Уверяю вас @mmr, упаковка в Linux на много проще.

Обратите внимание, что это решение не будет работать, если в установщике WIX есть несколько файлов проекта, и если вы пытаетесь собрать проект с помощью msbuild.

Несомненно, Майк точно знает, о чем говорит, при всем уважении, но я вздыхаю от отчаяния, когда думаю о том, что у меня в голове есть твердое понимание того, что делает установщик Windows. Прежде чем я это узнаю, я буду выполнять работу по консультированию по Java и .NET для корпоративных клиентов в ужасных городах технических центров, за кольцевой дорогой, заполнять свои отчеты TPS и удивляться, почему жизнь кажется такой пустой. Я думаю, что мой следующий проект может быть установлен с помощью NSIS, который, несмотря на все его недостатки, как нелепый язык, похожий на ассемблер, не помог мне понять, что делает установщик Windows.

@Tartley - используйте InnoSetup, это избавит вас от языка ассемблера :) Убедитесь, что вы также установили IStool, это очень помогает. Также - согласился, что для простой установки все это слишком сложно, но я думаю, что им действительно нужна эта сложность для установки чего-то вроде SQL Server 2008 ...

Пример на странице не работает должным образом wix.tramontana.co.hu/tutorial/upgrades-and-modularization/…. Я играл с этим. Можно даже перейти на более раннюю версию, если на странице указано, что это будет запрещено

@ Брайан Гиллеспи: что означает "... если есть неизмененные файлы ..."? По каким критериям установщик Windows решает, когда заменять файл, AssemblyVersion, AssemblyFileVersion, размер файла, ...?

@donttellya +1 усвоил это на собственном горьком опыте. RemoveExistingProducts был запланирован после InstallFinalize, и dll не обновлялись, поскольку assemblyVersion не изменилась, но другие поля, такие как AssemblyProduct, остались. Я не хочу зависеть от процедуры сравнения файлов - я просто хочу, чтобы предыдущее приложение УДАЛОСЬ

Я читаю раздел «Обновление и исправление» в книге Ника Рамиреса о Wix здесь, и он заявляет, что если вы планируете RemoveExistingProducts после InstallInitialize, вы ДОЛЖНЫ также запланировать <InstallExecute After = "RemoveExistingProducts" />. В вашем примере этого нет - значит ли это, что книга неправильная?

Я никогда не планирую InstallExecute явно.

Ради интереса, что вы делаете для мелких обновлений?

Я не. В WiX v3.6 Burn упростит выполнение незначительных обновлений, но без Burn требует ручного взаимодействия со стороны пользователя (необходимо указать параметры командной строки), что делает незначительные обновления практически бесполезными. :)

@RobMensching: как избежать установки старой версии поверх новой? Ваш ответ работает для меня (единственный пример "крупного обновления", который я могу вообще скомпилировать с WiX v3.5.2519.0), но можно установить более старую версию (после этого я вижу обе версии в "Добавить / Удаление программ »).

Хорошо, я только что нашел Элемент MajorUpgrade в этот ответ, который делает именно то, что я хочу, включая предотвращение перехода на более раннюю версию.

@RobMensching Можно ли удалить (удалить) более одного продукта с помощью wix во время установки msi, созданного wix. Я могу обновить предыдущую версию на новую с помощью wix, но мне нужно удалить все другие 2 приложения также во время этого обновления . Пожалуйста, ознакомьтесь с моим вопросом SO и направьте меня stackoverflow.com/questions/26863294/…

Спасибо за ссылку на эту статью ... это здорово!

Сообщение блога Боба Арсона об этом дает много полезной информации.

Примечание: нигде не задокументировано, но элемент «<MajorUpgrade>» должен быть размещен после<Package>. В противном случае candle выдает следующую ошибку: «ошибка CNDL0107: проверка схемы завершилась неудачно со следующей ошибкой в ​​строке 1, столбец 473: элемент« Продукт »в пространстве имен« schemas.microsoft.com/wix/2006/wi »имеет недопустимый дочерний элемент« MajorUpgrade »в пространстве имен« schemas.microsoft.com/wix/2006/wi ». Список из возможных ожидаемых элементов: 'Package'. ".

+1 Этот ответ должен получить как можно больше голосов; очень заманчиво пойти с ответом, который имеет в 5 раз больше голосов, но использует более старые подходы.

Хорошая точка зрения. Я добавил пример, чтобы люди не игнорировали его только потому, что у него его нет!

Просто хочу отметить, что вам не нужно указывать AllowDowngrades или AllowSameVersionUpgrades. По умолчанию они уже не работают.

Истинный. Я хотел, чтобы это было очевидно для всех, кто читает мой конкретный фрагмент кода, но, конечно же, это касается не всех!

Я изменил его на принятый ответ, так как он лучше, чем мои первоначальные выводы

Надеюсь, это не воскресит старую ветку, но я чувствую, что для создания «более новой» версии можно упомянуть еще пару вещей: 1) Вам нужно увеличить одну из первых трех цифр атрибута «Версия продукта». 2) Измените GUID в «Коде обновления продукта». 3) Поместите фактический GUID в атрибут «Package Id» (в отличие от рекомендуемой звездочки) и сохраните его постоянным во всех версиях. WIX выдает огромное предупреждение для GUID, но в противном случае он не будет работать как обновление.

Мой предыдущий комментарий неверен - игнорируйте его. То, что я описал, не жалуется при установке, не обновляется, как я думал. Поставьте звездочку в поле «Идентификатор продукта». Поместите фактический GUID в "Product UpgradeCode" - и НИКОГДА не меняйте его. Поставьте звездочку в поле «Идентификатор пакета». Наконец, когда вы увеличите числа в «Версии продукта», произойдет фактическое обновление.

Попробовал и получил "уже установлена ​​другая версия этого продукта"

То же, что и AriesConnolly, уже установлена ​​другая версия этого продукта ошибка

Насколько я понимаю, вы получаете эту ошибку, когда перекомпилировали программу установки без увеличения номера версии. Вы можете установить атрибут AllowSameVersionUpgrades на yes, но это имеет свои проблемы ...

Пакет: Тип идентификатора: Описание AutogenGuid: GUID кода пакета для продукта или модуля слияния. При компиляции продукта этот атрибут не следует устанавливать, чтобы разрешить создание кода пакета для каждой сборки. При компиляции модуля слияния этот атрибут должен быть установлен на guid модуляризации. ---- Значит, нам не нужно обращать внимание на идентификатор пакета, верно?

Ваша ссылка мертва