Hi Guys,

We have an MSI that installs an application which consists of few EXEs, some COM DLLs, and installs some fonts. However, the application has its own updater program which downloads new EXEs and DLLs from a network drive and replaces the local copies, but the problem is that windows installer detects that the files have been changed and runs the MSI repair which puts all of the original files back.

So ideally I would just like to disable the repair feature but from looking into it I think this is not something that is easy to do... and there seem to be a few different methods, so I'm just wanting to get some advice from you guys on what the best way of handling this situation would be :)

Thanks
Chris
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
The simplest route is to disable any advertised entry-points. These are probably limited to the shortcut(s) which launch the app. Convert these to "simple" shortcuts.
Answered 03/14/2011 by: VBScab
Red Belt

Please log in to comment
0
How does that help though? The repair starts before any shortcuts are run, it starts as soon as the updater program copies over the new versions of the EXEs
Answered 03/14/2011 by: chris128
Orange Belt

Please log in to comment
0
Then you probably have entry-points in the registry, almost certainly in the COM area (DLL registration).
Answered 03/14/2011 by: VBScab
Red Belt

Please log in to comment
0
Ah ok thanks, is that something I can 'fix' or is it going to be more trouble than its worth?
Answered 03/14/2011 by: chris128
Orange Belt

Please log in to comment
0
That depends on your level of knowledge and the tools you have at your disposal.

I suspect that the MSI was created by Visual Studio?
Answered 03/14/2011 by: VBScab
Red Belt

Please log in to comment
0
Well I'm not actually sure what the MSI was created with as I didn't create it - the application is an old VB6 app that had its own installer but that installer wouldn't play nicely with SCCM so we got one of the guys who helped set our SCCM system up to create a package for it. I assume he just looked at the files and registry keys etc that the original install was editing and mirrored that in the MSI, but I can always ask him exactly what he did and what he used if that will help.

I have fairly limited knowledge when it comes to MSI editing I'm afraid, I used Insted earlier today to fix some font installation issues in an MSI but that's the first time I've really used it. Its quite annoying that there isn't just a property you can set in an MSI to tell it not to self repair :(
Answered 03/14/2011 by: chris128
Orange Belt

Please log in to comment
0
To disable shortcuts entry points play with DISABLEADVTSHORTCUTS property.
Answered 03/14/2011 by: itolutions
Orange Senior Belt

Please log in to comment
0
In a pinch I suppose you could take the key files out of the components that contain these files. This way Windows Installer won't trigger a repair on em.
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
but like I said, the repair starts before I launch any shortcuts. It starts as soon as the EXEs and DLLs get replaced by the updater
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
ORIGINAL: pjgeutjens

In a pinch I suppose you could take the key files out of the components that contain these files. This way Windows Installer won't trigger a repair on em.


Will that have any side effects? I believe it will mean those files don't get removed when we uninstall but that's not a massive issue for us because this app is on pretty much every machine and very rarely gets uninstalled
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
Will that have any side effects? I believe it will mean those files don't get removed when we uninstall

It does not mean they will not get removed. It just means Windows Installer will have no 'hook' for the component to determine its sanity. Basically the key-file is the one that, if it's missing, triggers the repair for the entire component.

Suppose you have a component with 5 files in it. Only one of these is the keypath, and only if this one is missing will you get a repair. The other files are not 'monitored' so to speak.

EDIT: on a side note, another option might be to take out version info for the affected files in the File table, but that's something you'll have to experiment with, it's been awhile since I've had to do it myself.

PJ
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
OK thanks, well it sounds like removing the key files would be the best way to do it then. Can you tell me how I can do this or point me to any good guides etc? I had a look in the Components section and under each one there is FeatureComponents, File, and Registry. Do I just delete the File part of that? Kind of guessing here..
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
Easiest way to do this really is to do a direct table edit. You'd best start by making a backup of your original MSI first (you never know..)

First find out which components the files you want to work on are in (File Table, Component column)
Then go to the Component Table and delete the entries in the keypath column

PJ
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
So can I just do that for all of the components then? because I don't want any of them to be auto-repaired. There's only about 40 components listed so it won't take that long to do them all..
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
yes you could i guess, just make sure you test alot [:D]
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
OK I've edited the MSI to remove all of the KeyPath entries but now when I try to install it I find it installs to the E drive instead of C drive [&:] I can't find any reference anywhere within the MSI to E: so can anyone explain how I can make the default the C drive?
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
check the ROOTDRIVE property for the MSI.
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
Ah yeah thanks, I've been doing some research and found that same ROOTDRIVE property you mentioned so that's sorted that out.

However, my newly edited MSI doesn't seem to register any of the COM components that it is supposed to now :( The installation completes successfully but when I try to launch the application it just says "Component 'comctl32.ocx' or one of its dependencies not correctly registered: a file is missing or invalid"
I tried manually registering that OCX file with regsvr32 and then the program got further (just gave me a generic ActiveX error) so obviously the MSI is not trying to register the OCX and DLL files.

Is this likely to be because I removed the KeyPath? If so, how can I fix it?

Thanks
Chris
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
'comctl32.ocx

This looks like a missing merge module in your package. Did it contain any of those (more specifically Microsoft Common Controls Library)
You really wanna leave those components alone :)
Answered 03/15/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
You might have been better off sticking with the original VB6 package rather than repackaging it as an MSI, since you clearly have no need for Windows Installer technology in your situation. There's no self-healing technology in a VB6 package. I think you can run setup.exe silently with the /s switch.

In any case, back to your ugly MSI project, you're probably being tripped up by the advertising information. You probably need to convert everything to straight registry entries and clear out the advertising information so that your COM controls don't trigger self-healing. This is easier said than done, however. You essentially need to convert any advertising information to registry entries. You may have to recapture. You've also broken something to cause your controls to stop registering or to not register completely, so you should probably revert to your backup copy.

There may be a flaw in your autoupdate mechanism, too. If it's unregistering and re-registering your controls, it may be clearing the advertising information from the registry. If possible, the autoupdate installation mechanism should be revised to not unregister the controls in order to preserve the existing registry entries.

You shouldn't need to worry about clearing the file keypaths because you're probably not deleting any of the application's files during the autoupdates or application runtime. As long as the files exist, a self-repair won't be triggered in that way.

In short, it sounds like the MSI isn't built the way you want it to be able to support autoupdates without triggering a repair. You should probably not be using Windows Installer and should see if you can go back to using the VB6 project.
Answered 03/15/2011 by: mazessj
Blue Belt

Please log in to comment
0
Thanks, I wish we could use the VB6 installer but unfortunately it just doesn't seem to work with an SCCM OS deployment. You are correct saying that normally you can use the /s switch to execute the install silently (well, its not silent but it doesn't require any user input) and this works perfectly when I deploy it as a package to an existing live machine but it only works if we tick the "allow user to interact with program" option in the SCCM advertisement (even though the user doesn't need to interact with it, they just see the installation happening). The problem with that is that we want this to be included in our OS deployment task sequence and for that you cannot tick the "allow user to interact with program" option :( If anyone knows of a solution to this then I would gladly go back to the VB6 install
Answered 03/15/2011 by: chris128
Orange Belt

Please log in to comment
0
Chris
If you are using SCCM R2, there is an option to run the application as another user. This link explains how http://adventuresinosd.blogspot.com/2008/12/runas-in-sccm-2007-r2.html
Otherwise though i´m not sure it will work in OSD you can try making a wrapper msi. There is a video of it in appdeploy using wise.
Answered 03/15/2011 by: admaai
Orange Senior Belt

Please log in to comment
0
We are using SCCM R3 so we should have that option but I don't really see how that is going to help? I will give it a go anyway just in case though, thanks
Answered 03/16/2011 by: chris128
Orange Belt

Please log in to comment
0
That link was the only one I could find then, but the settings are a bit different, in Run command line task, "Command line" you can use setup.exe /s, do not tick the "start in", browse and set the Package, I usually set the timeout to something like 5 minutes, and set the user with the password(admin user), the task will then run the setup.exe /s as that user.
I usually enable Continue on error on Option tab too.
Answered 03/16/2011 by: admaai
Orange Senior Belt

Please log in to comment
0
Good news! The VB6 installer does seem to work if we run it as a command line program as you suggested :) Thanks a lot, I'm glad we don't have to mess about with this MSI anymore (though it seems daft that using an ancient installer actually works better than the latest windows installer technology).

Thanks to everyone else that replied as well :)
Answered 03/17/2011 by: chris128
Orange Belt

Please log in to comment
0
Don't knock what you don't understand. Windows Installer is perfectly capable of doing what you're doing, but it's a more advanced technology based on certain standards and has to be implemented differently than the way your package is currently built. Rather than stripping away the self-healing aspects (advertising, keypaths) which is a relatively easy thing for an experienced packager to do, you are simply avoiding the whole issue by using an old installation technology that lacks the robust capabilities of Windows Installer (self-repair, advertising, managed components, etc.)

I wouldn't say your "ancient" installer works better than Windows Installer. Simpler maybe, but not better.
Not to say Windows Installer doesn't have its share of aggravations, but it's still way more powerful than something like PDW.
Answered 03/17/2011 by: mazessj
Blue Belt

Please log in to comment
0
Chris I´m glad it worked. And I totally agree with mazessj, a well made msi, beats any other installer for windows.
Answered 03/17/2011 by: admaai
Orange Senior Belt

Please log in to comment
Answer this question or Comment on this question for clarity