Установщик не перезаписывает старую DLL, разветвленную для клиента

У меня есть проект MSS InstallShield 2012 Basic, который я поддерживаю для нашей компании. Я не обученный разработчик InstallShield (просто самый низкий [в то время) на тотемном столбе), но я набрал достаточно за месяцы, чтобы все работало гладко от версии к версии.

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

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

Когда я реплицировал их разветвленную установку и попытался обновить файлы, установщик запускается успешно и заменяет все, НО их разветвленные dll. Работа с "omus", "amus", принудительным перезаписыванием и т. Д. Ничего не меняет. Удаление файла заранее ничего не делает. Независимо от того, что я пытаюсь, разветвленные dll остаются, и журнал выглядит примерно так (имена изменены, чтобы защитить виновных, версии и руководства остались без изменений):

DLL, которая обновляется правильно:

Executing op: RegisterSharedComponentProvider(,,File=dll_that_works.r1,Component={B4F132E0-6C2A-4138-990B-16B991F8C54D},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=SY2F9C~1.DLL|dll_that_works.dll,SourceCabKey=dll_that_works.r1,DestName=dll_that_works.dll,Attributes=16384,FileSize=51584,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:\inetpub\wwwroot\Service\bin\dll_that_works.dll;    Overwrite;  Won't patch;    REINSTALLMODE specifies all files to be overwritten
Source for file 'dll_that_works.r1' is compressed

Разветвленная DLL, которая не обновляется:

Executing op: SetSourceFolder(Folder=C:\Windows\Installer\$PatchCache$\Managed\CA6D1F2B4A599A44A92536A1A31D3498\1.1.1)
Executing op: RegisterSharedComponentProvider(PatchGUID={EC6657A6-01A1-4AFC-86F9-1F4BF5F15481},MediaCabinet=#PCW_CAB_Family1,File=branched_dll.r,Component={74531F91-82A9-421D-A227-15DDDEDFC2FA},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=35952,PatchAttributes=0,PatchSequence=10000,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=branched_dll.r,SourceCabKey=branched_dll.r,DestName=branched_dll.dll,Attributes=0,FileSize=225664,PerTick=65536,,VerifyMedia=0,,TotalPatches=1,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:\inetpub\wwwroot\Service\bin\branched_dll.dll;  Overwrite;  Smart patch;    REINSTALLMODE specifies all files to be overwritten
Redirecting file copy of 'C:\inetpub\wwwroot\Service\bin\branched_dll.dll' to 'C:\Config.Msi\PTB2C9.tmp'.   A subsequent patch will update the intermediate file, and then copy over the original.
Source for file 'branched_dll.r' is uncompressed, at 'C:\Windows\Installer\$PatchCache$\Managed\CA6D1F2B4A599A44A92536A1A31D3498\1.1.1\'.

Это немного из моей глубины. Насколько я могу судить, он пытается исправить патч разветвленной DLL, не может этого сделать и по какой-то причине выбрасывает файл во временный каталог (я не смог найти подробности о том, что именно означает "умный патч"). Я видел такое с патчами, которые были применены к неправильной версии, но это не патч! Это обычный инсталлятор, который запускается с REINSTALLMODE=v(oa)mus и REINSTALL=ALL. Он должен просто увидеть старую версию, увидеть, что в нее встроена более новая версия, и удалить старую версию.

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

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

Я думаю, что предоставил все необходимое, но если нет, я могу предоставить больше информации. Я потратил большую часть сегодняшнего дня, глядя на это, и я просто не могу найти материал, похожий на этот сценарий.

1 ответ

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

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

Другие вопросы по тегам