Instalator nie nadpisuje starej biblioteki DLL, która została rozgałęziona dla klienta

Question

Mam projekt InstallShield 2012 Basic MSI, który utrzymuję dla naszej firmy. Nie jestem wyszkolonym programistą InstallShield (tylko najniższym w tym momencie) na słupku totemowym), ale w ciągu miesięcy zebrałem dość, aby wszystko działało sprawnie od wersji do wersji.

Niedawno jeden z naszych klientów nalegał, aby naprawić błąd w starszej wersji naszego produktu, który został już naprawiony w najnowszym wydaniu. Zazwyczaj nie tworzymy poprawek, ponieważ pełnoprawny instalator podwaja się jako aktualizator, ale w tym przypadku spełniliśmy wymagania, utworzyliśmy gałąź w wersji, w której się znajdowali i wysłaliśmy łatkę aktualizacyjną. W tej łatce znalazł się tylko jeden plik, który miał tę samą wersję, co zastępowany plik. Wszystko było dobrze.

Dzisiaj ten klient chce uaktualnić do naszej najnowszej wersji. Skutecznie łączymy ich gałęzie z powrotem do mainline, a ponieważ ich oddział nie ma żadnych dodatkowych komponentów lub kodu specyficznego dla klienta, pomyślałem, że możemy po prostu dać im nasz zwykły instalator i to wszystko zastąpi. Nie tak ...

Kiedy replikowałem ich rozgałęzioną instalację i próbowałem zaktualizować pliki, instalator działa poprawnie i zamienia wszystko, ALE ich rozgałęziona biblioteka dll. Majstrowanie przy "omus", "amus", wymuszanie nadpisywania itp. Niczego nie zmienia. Usunięcie pliku wcześniej nic nie robi. Bez względu na to, co staram dll rozgałęzione pozostaje i dziennik wygląda mniej więcej tak (imiona zmienione, by chronić winnych, wersje i GUID pozostały nienaruszone):

DLL, który aktualizuje poprawnie:

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 

rozgałęzione DLL nie aktualizuje się:

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

To jest trochę poza moją głębią. W pobliżu, jak mogę powiedzieć, stara się łatać rozgałęzione DLL, nie może tego zrobić, i z jakiegoś powodu wyrzuca plik do katalogu tymczasowego (nie mogłem znaleźć szczegółów na temat tego, co oznacza "inteligentna łata"). Widziałem, że dzieje się tak z łatkami, które zostały zastosowane do niewłaściwej wersji, ale to nie jest łatka! Jest to zwykły instalator uruchamiany z REINSTALLMODE = v (oa) mus i REINSTALL = ALL. Powinna po prostu zobaczyć starszą wersję, zobaczyć, że ma nowszą wersję osadzoną, i wysadzić starą wersję z dala.

(Na kaprysu próbowałem aktualizacji DLL ręcznie zamiast używania updater daliśmy klient. Wszystko zaktualizowane prawidłowo, więc to nie dławiąc się samego pliku)

Moja najbliższa celem jest, aby tego klienta z powrotem zsynchronizowane, najlepiej bez odinstalowywania i z jednym zunifikowanym instalatorem, zamiast tworzyć specjalny aktualizator tylko dla nich. Ponieważ pliki są już na wolności, jeśli to niemożliwe, mogę znieść wyjątkowy przypadek. Moim przyszłym celem jest uczynienie tego po prostu naturalnie, jak zakładałem, że będzie - plik jest starszą wersją, plik zostaje zastąpiony, nic innego się nie liczy.

Chyba warunkiem wszystko istotne, ale jeśli nie mogę podać więcej informacji. Większą część dnia spędziłem na oglądaniu tego i po prostu nie mogę znaleźć żadnego materiału podobnego do tego scenariusza.

Answer 1

Z opisu scenariusza wynika, że ​​jego brzmienie, takie jak "zmodyfikowana data" pliku klucza dla skorygowanego składnika dla klienta, może być późniejsze niż data w pakiecie aktualizacji, ale wersje są takie same. Instalator Windows może nie zastępować pliku. Zobacz: Replacing Existing Files i przykład w wierszu dla FileF

Ten klient może potrzebować niestandardowego pakietu, który odinstalowuje poprawiony komponent przed zastosowaniem najnowszej aktualizacji.