Il programma di installazione non sovrascrive una vecchia DLL ramificata per un client

Question

Possiedo un progetto MSI di InstallShield 2012 Basic che sto mantenendo per la nostra azienda. Non sono uno sviluppatore InstallShield addestrato (solo il più basso [al momento] sul totem), ma ho raccolto abbastanza nei mesi per far funzionare tutto senza problemi da una versione all'altra.

Recentemente uno dei nostri clienti ha insistito per correggere un bug in una versione precedente del nostro prodotto che avevamo già corretto nella versione più recente. Normalmente non creiamo patch poiché l'intero programma di installazione funge anche da programma di aggiornamento, ma in questo caso abbiamo aderito, creato una filiale alla versione in cui si trovavano e inviato loro una patch di aggiornamento. In quella patch era incluso un solo file e aveva la stessa versione del file che stava sostituendo. Tutto andava bene.

Oggi quel cliente desidera effettuare l'aggiornamento alla nostra ultima versione. In effetti stiamo unendo il loro ramo alla linea principale, e dal momento che il loro ramo non ha componenti aggiuntivi o codice specifico per il client, ho pensato che potremmo semplicemente dare loro il nostro normale programma di installazione e fare in modo che sovrascrivano tutto. Non così ...

Quando ho replicato la loro installazione ramificata e ho provato ad aggiornare i file, il programma di installazione viene eseguito correttamente e sostituisce tutto MA la loro DLL ramificata. Armeggiare con "omus", "amus", sovrascrivere la forza, ecc. Non cambia nulla. Cancellare il file in anticipo non fa nulla. Non importa quello che provo la dll ramificata rimane e il registro simile a questa (nomi cambiati per proteggere i colpevoli, le versioni e GUID lasciati intatti):

DLL che aggiorna correttamente:

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 ramificata che non aggiorna:

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\'. 

Questo è un po 'fuori dalla mia profondità. Per quanto posso dire, sta provando a correggere la DLL ramificata, non è possibile farlo e getta il file in una directory temporanea per qualche motivo (non sono riuscito a trovare dettagli su cosa significasse esattamente "patch intelligente"). L'ho visto succedere con le patch applicate alla versione sbagliata, ma questa non è una patch! È un normale programma di installazione eseguito con REINSTALLMODE = v (oa) mus e REINSTALL = ALL. Dovrebbe solo vedere la versione precedente, vedere che ha una versione più recente incorporata e far saltare via la vecchia versione.

(Per un capriccio ho provato ad aggiornare la DLL manualmente invece di utilizzare il programma di aggiornamento che abbiamo dato al cliente. Tutto aggiornato correttamente, quindi non è soffocamento sul file stesso)

Il mio obiettivo immediato è quello di ottenere questo client indietro in sincrono, preferibilmente senza alcuna disinstallazione e con un programma di installazione unificato invece di creare un programma di aggiornamento speciale solo per loro. Dato che i file sono già in circolazione, se non è fattibile, posso sopportare un caso speciale. Il mio obiettivo futuro è di farlo funzionare in modo naturale come pensavo sarebbe - il file è una versione precedente, il file viene sostituito, nient'altro conta.

Penso di aver fornito tutto quanto pertinente ma se non posso fornire ulteriori informazioni. Ho passato la parte migliore di oggi a guardare questo e semplicemente non riesco a trovare alcun materiale simile a questo scenario.

Answer 1

Dalla tua descrizione dello scenario, sembra che la "data di modifica" del file chiave per il componente che hai patchato per il tuo cliente possa essere successiva alla data nel pacchetto di aggiornamento, ma le versioni sono le stesse. Windows Installer potrebbe non sostituire il file. Vedere Replacing Existing Files e l'esempio nella riga per FileF

Questo cliente potrebbe dover utilizzare un pacchetto personalizzato che disinstalla il componente con patch prima di applicare l'aggiornamento più recente.