At times, following our installations, the Windows Installer attempts to repair our application. I know this is due to a damaged or missing KeyPath and I am able to track the problematic component(s) through the event viewer.
My only question is what could be a possible cause of this? The problems usually involve components that, from an installation development standpoint, haven't changed. I pull my installation source files from a developer's box and place them in the appropriate directory on my installation development machine. That's basically it. I make any necessary changes to the template (bump version, change product/package code, etc.) then initiate the build.
Some of the components that have caused problems contain files which have been changed on the developer's side, different version, etc. However, at times, other problematic components contain files which haven't been altered in any way.
I hope someone can lend a hand in this!
Thanks!
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Broken KeyPath
Started by
Superfreak3
, May 21 2002 20:17
4 replies to this topic
AdamBell
-
- Members
- 21 posts
Posted 25 May 2002 - 20:24
SF3,
Nothing jumps out at me when I read your post, so I don't have a watertight answer.
I wonder if the packages in question have been validated? If there is no warnings or errors on the components in question, I'd start debugging, commencing with generating a log on install (the MSI.chm has the command line params) e.g. /q*v c:\temp.
Without knowing what scenario caused the repair it's hard to comment. I have seen (occassionaly) the situation where the first time an application is run, it kicks off a repair. This can be worked around by taking a snap shot of that (the repair), and seeing what it's doing. If required this is then imported into the package and TESTED
Hope this might point you in the right direction.
Cheers
Adam
Nothing jumps out at me when I read your post, so I don't have a watertight answer.
I wonder if the packages in question have been validated? If there is no warnings or errors on the components in question, I'd start debugging, commencing with generating a log on install (the MSI.chm has the command line params) e.g. /q*v c:\temp.
Without knowing what scenario caused the repair it's hard to comment. I have seen (occassionaly) the situation where the first time an application is run, it kicks off a repair. This can be worked around by taking a snap shot of that (the repair), and seeing what it's doing. If required this is then imported into the package and TESTED
Hope this might point you in the right direction.
Cheers
Adam
AdamBell
-
- Members
- 21 posts
Posted 25 May 2002 - 20:53
oops - that is of course l*v c:\temp (not /q *wink*). I've just been working with UI command switches and got my wires crossed
Adam
Adam
Superfreak3
-
- Full Members
- 437 posts
Posted 29 May 2002 - 13:32
Thanks for the info Adam. I checked the verbose installation log and didn't find anything that looked out of the ordinary (for the two components involved in the repair trapped by the Event Viewer).
The two components with damaged/missing KeyPath's were DAO350.dll, which we haven't touched, and a self extracting .exe created by us.
You mentioned taking a 'snap shot' of the repair to develop a work around. What do you mean by this?
Thanks in advance!
The two components with damaged/missing KeyPath's were DAO350.dll, which we haven't touched, and a self extracting .exe created by us.
You mentioned taking a 'snap shot' of the repair to develop a work around. What do you mean by this?
Thanks in advance!
AdamBell
-
- Members
- 21 posts
Posted 31 May 2002 - 15:50
SF3 and I discussed this offline.
For the sake of finishing the thread:
If you know that the reapir is triggered by certain events, prep a workstation, load your snap shot software (Disco, Wise ...) but don't perform the initial snap shot.
Install the package, and set everything up just prior to your known "trigger" point that causes the repair.
Perform the initial snap shot.
Trigger the repair
Perform after snap shot and create package
Examine what you captured to see what was causing the repair. Sometimes its data that needs to be incorporated into the original package, sometimes not. Generally whatever you captured gives you the solution to the problem though
Cheers
Adam
For the sake of finishing the thread:
If you know that the reapir is triggered by certain events, prep a workstation, load your snap shot software (Disco, Wise ...) but don't perform the initial snap shot.
Install the package, and set everything up just prior to your known "trigger" point that causes the repair.
Perform the initial snap shot.
Trigger the repair
Perform after snap shot and create package
Examine what you captured to see what was causing the repair. Sometimes its data that needs to be incorporated into the original package, sometimes not. Generally whatever you captured gives you the solution to the problem though
Cheers
Adam