Установщик Windows "Ошибка 1308. Исходный файл не найден" при удалении исправления в сценарии последовательности

Question

Мне требуется ряд неустановимых исправлений, созданных с помощью Patch Design с Installshield 2012. Первые два исправления работают нормально при удалении. Однако третий патч, если и только если он был удален, когда патч 1 и / или патч 2 уже были применены, выдает ошибки:

MSI (c) (48:C4) [19:02:54:135]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1308.Source file not found: {pathToFile}.  Verify that the file exists and that you can access it.

Существует 26 таких ошибок относительно разных файлов. Там нет очевидного шаблона для файлов или компонентов, или есть функции

Примечание. Если у меня есть только исправление 3, удаление НЕ приводит к этой ошибке.

Я создал все три патча с одинаковыми параметрами в Patch Design. Единственное заметное отличие, которое я понимаю, состоит в том, что патч 3 содержит гораздо больше изменений (обновлений файлов), чем первые два. Позвольте мне повторить: еще много изменений.

Мои вопросы:

1. Почему это происходит только в том случае, если установлена ​​серия патчей, а не только третий патч?

2. Что я должен сделать, чтобы предотвратить удаление пакета исправления, чтобы попытаться извлечь файлы из местоположения, которое должно быть только для времени разработки при создании исправления? Или, может быть, это выборка, но кэш слишком перегружен или запутан?

ОБНОВЛЕНИЕ - ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ (запрошено Glytzhkof): патч содержит 96 файловых изменений, что примерно вдвое меньше базового пакета MSI. Это на самом деле от ветки Dev. Было добавлено несколько новых файлов. Некоторые были первоначально удалены (пришлось вернуть их обратно, когда я обнаружил, что мы действительно делали патч...). Если бы я описал ситуацию больше, это может обидеть вас как профессионала в этой области.

Я пытался продать Major Upgrade, и установщику потребовалось бы всего несколько настроек, чтобы сделать его ненужным для исправлений. Для удаления нашего продукта требуется параметр, чтобы он не был интерактивным (нам нужен этот параметр для работы в сценарии крупного обновления, в настоящее время он является только частью последовательности удаления). Это единственная реальная проблема - но ее исправление окупится. Однако было решено не решать эту проблему. Я пытаюсь "поднять" эту проблему на каждой итерации. Нет кости. Мне сказали, что нам нужны патчи для крупных релизов - поэтому здесь я пытаюсь заставить хвост вилять собакой.

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

ДРУГОЕ ОБНОВЛЕНИЕ: файлы, упомянутые в ошибках 1308, не на целевой системе %windir%Installer\$PatchCache$\Managed\{PackedProductCodeOfMyBaseMSI??}

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

Answer 1

Я все еще ищу решение или, по крайней мере, какое-то руководство, хотя я согласен с тем, что это выходит за рамки обычной хорошей практики. - Джек 1 час назад

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

Для меня патч MSI эффективен для 2 основных сценариев:

1. Исправлена ​​ошибка в последовательности удаления установленного продукта с небольшим обновлением.
2. Вы предоставляете небольшое обновление для пары файлов в качестве " исправления " для выпущенного продукта, который может быть огромным и требует много времени для переустановки.

Для этих двух целей я несколько раз профессионально использовал исправления MSI. В каждом случае не было другого хорошего решения. Патчинг IMHO предназначен для "исправления" - это то, для чего предназначена вся технология, а не для развертывания частых, постепенных обновлений. Доставка 96 обновлений файлов НЕ является исправлением.

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

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

Условия исправления и настраиваемого действия: для меня один из худших аспектов исправления состоит в том, что настраиваемые действия в пакетах могут не быть настроены должным образом, чтобы НЕ запускаться при выполнении операции исправления в отличие от обычной установки. Патч обладает свойствами, специфичными для патча, такими как PATCH и MSIPATCHREMOVE. Используйте эти условия для пользовательских действий, чтобы они запускались или не запускались во время исправления в зависимости от того, что необходимо. Будьте осторожны с условиями пользовательских действий, они сложны, чтобы получить право. Вот " Листок условий MSI ", чтобы помочь вам. Я не проверял эти условия - тестирование является единственной гарантией.

Некоторые дальнейшие советы по исправлению:

• Я бы полностью забыл об основных обновлениях. Я попробовал их и попробую снова, но они, как правило, не идеальны. Абсолютным требованием для исправления основного обновления является то, что RemoveExistingProducts помещается после InstallFinalize в InstallExecuteSequence. Причина этого заключается в том, что в противном случае файлы удаляются до того, как пакет исправлений попытается исправить существующие файлы. Вполне улов 22.
• Незначительное обновление не удаляет существующую установку, но rater повторно кэширует новый файл MSI, чтобы использовать его для операций обслуживания и удаления. Это означает, что патч может исправить последовательность удаления до его запуска - один из хороших патчей использует тот, который я перечислил выше. Фактически, если незначительное обновление работает, патч может не понадобиться вообще. Просто используйте незначительное обновление, если ваш MSI-файл не очень большой и вы не хотите поставить небольшое "исправление".
• Если вам нужно включить файлы в ваш патч, я рекомендую включить " включать целые файлы ". В противном случае выполняется исправление на уровне битов, и это лишняя сложность (если ваши двоичные файлы огромны). Я также не уверен, как исправление на уровне битов работает с подписанными файлами и цифровыми подписями.
• Включите в патч только то, что вам нужно. Добавьте не файлы или настройки, которые не требуются, и вы можете сделать надежный патч. Избегайте добавления пользовательских действий, если это возможно.
• Как уже упоминалось: имейте в виду, что исправление использует тот же InstallExecuteSequence, что и обычная установка, но вы можете по-разному обусловить настраиваемые действия с помощью свойств, специфичных для исправления, таких как PATCH и MSIPATCHREMOVE. Используйте эти условия для пользовательских действий, чтобы они запускались или не запускались во время исправления в зависимости от того, что необходимо.
• Ссылка на компонент должна быть на 100% правильной, чтобы ЛЮБОЙ тип патча работал. Без исключений.
• Незначительные обновления должны быть запущены с правильной командной строкой msiexec.exe, чтобы работать, если они не доставлены через setup.exe / update.exe.
• Сторонние модули слияния часто вызывают проблемы с исправлениями в моем опыте.
• " Ложная версия ", как они ее называют, - черное искусство обеспечения того, чтобы файлы всегда обновлялись путем добавления другой версии в MSI-файл для файла на диске, что, похоже, приводит к ошибкам исправления.
• Патч покажет тот же графический интерфейс, что и основная установка. На мой взгляд, это ошибочный дизайн. Пользовательские действия в графическом интерфейсе могут испортить процесс исправления (следует ли принимать новый пользовательский ввод значений для исправления?).
• Я считаю, что каждый патч должен быть накопительным - заменять все предыдущие патчи. Я никогда не получал эту работу должным образом, когда тестировал несколько патчей, установленных последовательно и последовательно. По многим причинам я пришел к выводу, что это был бесполезный подход к исправлению с самого начала. У меня были проблемы, точно такие же, как вы описываете с семействами исправлений, целевыми выпусками и т. Д. Патч не слишком умен, он представляет собой сложный набор из нескольких файлов, пытающихся найти продукт, к которому он принадлежит.

Очевидная вещь, которую следует заключить, заключается в том, что я действительно не рекомендую использовать такой подход к исправлению, даже когда вас об этом попросят. Тем не менее, я прочитал эту ветку, которая, кажется, указывает на успешное исправление для кого-то, кто перешел на использование WIX вместо Installshield. Вы должны проверить ссылку CodeProject тоже.

Что касается сценария развертывания - я не полностью осознаю все его аспекты, но похоже, что разработчики хотят, чтобы исправления преобразовывали работающее приложение в текущую версию QA через исправление? Я бы никогда не согласился с этим, иначе сценарий должен отличаться от того, на что он похож. Полностью потраченные впустую усилия по созданию патча, когда вы уже должны вначале выпустить незначительные или крупные обновления - их более чем достаточно для поставки программного обеспечения для обеспечения качества. Вы можете использовать dev-branch для доставки отдельного MSI, а затем время от времени создавать несколько исправлений, чтобы проверить исправимость продукта, но я бы никогда не использовал исправления для внутренней доставки установщиков вашего продукта. Я не знаю, если это то, что вас просят сделать.

Работайте с небольшими и крупными обновлениями - желательно последними для исправлений, не требующих исправлений, и доставляйте исправления, когда они вам действительно нужны. Если продолжительность установки является проблемой, вы можете просто запланировать ежедневное масштабное обновление после завершения ночной сборки на всех компьютерах разработчика и QA? (включая уничтожение любых запущенных процессов, необходимых для работы установки). Я не знаю, полностью ли я не в курсе того, чем на самом деле является ваш сценарий.

Посетите сайт installsite.org Стефана Крюгера, чтобы узнать больше обновлений и советов по исправлению.

Посмотрите этот хорошо известный учебник по wix для обновлений и исправлений. И MSDN.

Answer 2

Я должен добавить это как ответ, так как это слишком долго для комментария. 200 изменений файла? Я предполагаю, что стоимость файла займет больше времени, чем установка всего незначительного обновления. На вашем месте я бы отказался доставлять такие патчи. Они обречены на неудачу, с почти 100% уверенностью из-за сложности технологии. Помните, что MSI-патч - это всего лишь механизм доставки уже работающего обновления, в основном с добавленным риском и сложностью. Это действительно так.

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

Можете ли вы описать сценарий немного лучше? Я считаю, что автоматизированные процессы сборки, обеспечивающие крупные обновления, работают очень хорошо, чтобы доставлять ежедневные сборки в QA. Если скорость установки является проблемой, вы можете использовать методы, чтобы ускорить процесс, такие как включение MSIFASTINSTALL. С помощью этого свойства вы можете указать системе выполнять менее тяжелые и длительные операции, такие как создание точки восстановления системы и тщательную оценку стоимости файлов (сравнение установленных и устанавливаемых файлов и размеров каталогов).

Answer 3

Я бы посмотрел любую из статей поддержки об этой ошибке, из которых есть несколько. В некоторых случаях они могут относиться к конкретному продукту, но могут указывать на ошибку (например, административные установки или ошибки в установщике Windows). Может быть, вы уже сделали это.

В противном случае эти проблемы, как правило, возникают, когда параметры замены исправления каким-либо образом неверны. Если вы как-то сказали, что один из патчей заменил другой, то по определению он включает в себя все изменения патча из предыдущих патчей. Поскольку это связано с работой с направляющими в разных местах, возможно, было пропущено изменение, если использовался один и тот же базовый файл PCP, хотя я не уверен, насколько IS скрывает или скрывает все это. Конечным результатом будет то, что Windows будет думать, что другие патчи больше не нужны, и удалит их. Это может помочь:

http://msdn.microsoft.com/en-us/library/aa368345%28v=vs.85%29.aspx

Answer 4

Обращение к этой рекомендации слишком длинно для комментария, поэтому:

Кэширование копии фактической установки MSI локально всегда было хорошей идеей (ищите Дао правил установщика Windows) в случае восстановления, добавления функций и т. Д., Но статья Хита о 5.0 изменениях файла MSI с внутренним кэшированием, который не является тоже самое. IS может сказать "держать копию действительного файла MSI доступным", Хит просто описывает внутреннее изменение "секретного" кэшированного файла MSI, но этот MSI с внутренним кэшированием не считается допустимым источником. Будьте уверены, что "кэшированные" они имеют в виду. Я думаю, что они означают, что вы должны держать копию фактического MSI доступной при установке.

Я предполагаю, что IS видит основную проблему не столько как отсутствующий патч, сколько как Windows, нуждающаяся в восстановлении исходных файлов при удалении патча, поэтому, если файл msp недоступен, он может получить его из исходного виртуального MSI файл, который состоит из оригинальных плюс патчи. Если вы используете опцию IS в кэшированном MSI, я предполагаю, что он куда-то копирует файл MSI и устанавливает его оттуда, или иным образом делает это местоположение допустимым источником. В случае необходимости восстановления файлов при удалении исправления, их анализ состоит в том, что это можно сделать (автоматически?), Используя (базовый MSI + все применимые исправления) для восстановления предыдущих файлов. Я пытаюсь прочесть мысли И.С. из вашего краткого комментария, и, возможно, это поможет, хотя я уверен, что не совсем точно понял.