9 replies to this topic

[ali]

Hallo,
wenn ich ein Patch auf unsere installation ausführe, bekomme ich die folgende Meldung:
Aktion 16:09:18: PatchFiles. Dateien werden gepatcht
MSI (s) (38:A0) [16:09:18:330]: Executing op: ProgressTotal(Total=339727502,Type=0,ByteEquivalent=1)
MSI (s) (38:A0) [16:09:18:330]: Executing op: ChangeMedia(,MediaPrompt=Bitte legen Sie den Datenträger ein: ,MediaCabinet=PCW_CAB_Family1,BytesPerTick=0,CopierType=2,ModuleFileName=C:\WINDOWS\Installer\42415.msp,,,,,)
MSI (s) (38:A0) [16:09:18:330]: Executing op: CacheBaselineFile(Baseline=0,FileKey=MyDll.DLL,FilePath='C:\Programme\meineFirma\MyDll.DLL' ,,Existing=0)
MSI (s) (38:A0) [16:09:18:330]: Executing op: PatchApply(PatchName=MyDll.DLL' ,TargetName='C:\Programme\meineFirma\MyDll.DLL' ,PatchSize=2394,TargetSize=856816,PerTick=0,,FileAttributes=16384,PatchAttributes=0,CheckCRC=0)
MSI (s) (38:A0) [16:09:18:330]: Patch for file 'C:\Programme\meineFirma\MyDll.DLL' is redirected to patch 'C:\Config.Msi\PT60.tmp' instead.
PatchFiles: Datei: MyDll.DLL' , Ordner: C:\Programme\meineFirma\, Größe: 856816
MSI (s) (38:A0) [16:09:18:361]: Re-applying security from existing file.
MSI (s) (38:A0) [16:09:18:361]: SOFTWARE RESTRICTION POLICY: Verifying object --> 'C:\WINDOWS\Installer\42415.msp' against software restriction policy
MSI (s) (38:A0) [16:09:18:361]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\42415.msp has a digital signature
MSI (s) (38:A0) [16:09:19:783]: SOFTWARE RESTRICTION POLICY: C:\WINDOWS\Installer\42415.msp is permitted to run at the 'unrestricted' authorization level.MSI (s) (38:A0) [16:09:19:799]: Note: 1: 2318 2: C:\Config.Msi\PF7C.tmp
MSI (s) (38:A0) [16:09:19:799]: Note: 1: 2302 2: 0
MSI (s) (38:A0) [16:09:19:830]: Note: 1: 1328 2: C:\Config.Msi\PT60.tmp 3: -1072807676
MSI © (44:A0) [16:09:19:846]: Transforming table Binary.

MSI © (44:A0) [16:09:19:846]: Transforming table Binary.


Das Patchen hat bisher immer funktioniert, dies war das erste Release, das wir mit einer Digitalen Signatur ausgeliefert haben. Muss ich noch was beachten?

Edited by ali, 07 December 2007 - 16:35.

[Stefan Krueger]

Ich sehe keine Fehlermeldung. Wo liegt das Problem?

[ali]

das Problem besteht darin, das der Patch nicht angewendet werden kann, wenn ich eine Datei anhand der Binären unterschiede Patchen will, wenn diese signiert ist. Der Installer bringt ne Fehlermeldung, das die Datei nicht aktuallisiert werden kann, weil wohl bereits ein anderer Patch dies Datei aktualisiert hat. Dies ist nicht der Fall, die zu Patchende Komponente ist dieselbe wie die auf die das Patch generiert wurde.Ich bin nach ein bisschen Forschen im Web darauf gestoßen, das dies evtl. mit Sicherheitseinstellungen bei der Patch Erstelung oder Anwendung zusammenhängen kann, weiß aber nicht so recht wo ich ansetzen soll. Wenn ich die Komponenten als ganzes ersetze, habe ich keine Probleme mit dem Patch.

Edited by ali, 10 December 2007 - 12:39.

[ali]

bei der Meldung oben wurde was abgeschnitten:


MSI © (44:A0) [16:09:19:846]: Transforming table Binary.
Note: 1: 2262 2: Binary 3: -2147287038
Information 2835. The control ErrorIcon was not found on dialog SetupError.
Fehler 1328. Fehler bei der Anwendung des Patch auf Datei C:\Config.Msi\PT60.tmp. Die Datei wurde wahrscheinlich bereits auf andere Weise aktualisiert und kann von diesem Patch nicht mehr verändert werden. Wenden Sie sich mit Fragen an Ihren Patch-Hersteller. Systemfehler: -1072807676
MSI (s) (38:A0) [16:22:17:939]: Produkt: TestSoftware -- Fehler 1328. Fehler bei der Anwendung des Patch auf Datei C:\Config.Msi\PT60.tmp. Die Datei wurde wahrscheinlich bereits auf andere Weise aktualisiert und kann von diesem Patch nicht mehr verändert werden. Wenden Sie sich mit Fragen an Ihren Patch-Hersteller. Systemfehler: -1072807676

Die Meldung ist total konfus, weil sie nur kommt, wenn ich eine Komponente aktualisieren will, die im vorherigen Paket signiert war. Wenn ich unsignierte Komponenten aktualisieren will, hat das immer funktioniert, und tut es auch in diesem Fall noch immer.
Wenn ich die Komponenten komplett einschließe, funktioniert es.

Edited by ali, 10 December 2007 - 12:38.

[Stefan Krueger]

Signierst du "von Hand oder lässt du InstallShield das erledigen? D.h. wenn du den Patch erzeugst, legst du dann die signierte alte Datei zu Grunde, oder die unsignierte? In letzterem Fall würde sich durch das Sinieren die Checksumme ändern, d.h. die (unsignierte) Datei für die der Patch erstellt wrde hat eine andere Checksumme als die (signierte) Datei auf dem Zielsystem.

[ali]

Hallo,
ich denke wir kommen den Problem etwas näher. Wir haben 3 Release ausgeliefert. Einmal ein komplettes Web Image nur als exe, ein Web Image für ein automatisches Admin Setup und dann noch ein CD Image das in cab files erstellt wurde.
Alle Release wurde beim Erstellen signiert von IS. D.h. das hier die Komponenten in jedem Release erneut signiert wurden.
Jetzt habe ich aber mittlerweile herausgefunden, das das Problem nicht nur mit den signierten Komponenten besteht, sondern auch mit unsignierten. Kann das an den 3 Unterschiedlichen Release liegen? muss ich wirklich für jedes Release einen eigenen patch generrieren und ausliefern?

[ali]

Hallo,
ich habe folgendes getan:

Das erste ausgelieferte Web image mit setup.exe /a entpackt und für das zu erstellende Patch als Source genommen. Dieses Paket beinhaltet also auch alle signierten Komponenten.
Dann habe ich das SP1 erstellt auch als Web Image, dieses auch mit Setup.exe /a entpackt und als Ziel für den Patch genommen. Hier sind auch alle Komponenten wieder signiert.
Dann habe ich mein Patch erstellt und zwischen den beiden Paketen die Differenz ertstellt.
Dennoch lässt sich das Patch nicht anwenden, weil bei jeder signierten exe, dll und ocx die Fehlermeldung kommt, das obwohl genau die Pakete als Grundlage genommen wurden, die mit IS erstellt wurden.
Ich kriegs nicht auf die Reihe

Edited by ali, 15 January 2008 - 10:08.

[ali]

hat keiner ne Idee?

[ali]

ich denke mal ich habe es jetzt genau überprüft.
Mir ist nun klar geworden, das man mit IS nicht signieren darf, jedenfalls nicht wenn man sich die Option des Patchens offen halten will.
Mein Problem ist wohl, das ich zum einen ein Minor Upgdate ausliefere das eine Vollinstallation ausführt, oder eine aktualisierung auf die letzte Version. Gleichzeitig liefere ich auch ein Patch aus, der nur die Aktualisierung über Web vornimmt.
als Source habe ich eine CD und ein Web Image. Da beide nicht zum selben Zeitpunkt compiliert wurden, haben die Komponenten unterschiedliche timestamps durch das signieren, evtl auch ander Hashwerte. Das passt jetz alles nicht zusammen, ich müsste für jedes Paket ein eigenen Patch erzeugen, um Patches nur mit binären Unterschied auszuliefern. Wir liefern daher ein Patch aus in dem die Komponenten komplett aufgenommen wurden. Da gibts keine Probleme.

[MegDino]

Hallo zusammen,
ich habe das selbe Problem wie Ali hier:
1) Eine Erstinstallation von CD
2) Patches im Online-Update mit Binärdifferenzen
3) Eine CD die sowohl als Vollinstallation als auch als Minor Update auf eine vorhandene Installation angewendet werden kann.

Nach Installation 1) startet man ein Update 2). Einen Monat später erscheint eine Update CD 3) die neuer ist, als der gepatchte Stand. Bei Installation dieser CD kommt dann die Fehlermeldung "Fehler bei der Anwendung des Patch auf Datei C:\Config.Msi\xxxx.tmp".

Nach Alis Erkenntnissen liegt der Grund nun darin, dass der Hash-code durch das Patchen verändert wurde und damit das Minor-Update die Datei als "unpassend" identifiziert.

Was bei uns nun geholfen hat, ist das Löschen des Ordners "C:\Config.msi" auf dem Zielrechner. Aber ich weiß nicht, ob man sich dadurch andere Probleme einhandelt.

Ist der einzige, saubere Weg für mich aus der Minor-Update CD ein Major-Update zu machen, bzw. die vorhandene Installation erst zu deinstallieren???

Grüße
Meg

Edited by MegDino, 02 February 2011 - 09:44.