/build/static/layout/Breadcrumb_cap_w.png

Issues with full upgrade package

Hi all,

I've got two issues with a major upgrade package that I'd like to run by you. Firstly, this major upgrade package has come about because we have an application and the existing installation package didn't have key paths correctly configured for user components. So this package is the exact, original package but I'm using regkeys as the key paths rather than files. I've also separated the user components into a new feature. Because of this a major upgrade is required.

So my two issues are:

1. I've put the existing upgrade code and version into the upgrade table. The upgrade occurs but it's not behaving how I'd like. It performs the install first, and then uninstalls the previous version. Because the files of both packages are the same, it's actually removing all the HKLM keys and c: files that it just installed. When the user runs an advertised shortcut, it's repairing all this. Now although that appears to be working, I'd prefer it perform the uninstall first and then the install, that way the advertised shortcut is just healing the user components. Is this possible?

2. I'm told users access this application in various ways besides just the advertised shortcuts. For instance, they may have created shortcuts to the application on their desktop or in their quick launch (we're still using XP). Additionally, another application that user's use regularly can call this application. We've found (as you'd suspect) that if you access the application via a quick launch shortcut or try and run it through its integration with the second program, no self-heal is occuring. Is there a way around this? Will active setup be the only answer here?

I appreciate everyone's feedback, thanks.

0 Comments   [ + ] Show comments

Answers (9)

Posted by: anonymous_9363 13 years ago
Red Belt
0
1. Check the location of the RemoveExistingProducts standard action. Microsoft recommends that it go near the end of the sequence for precisely the reasons you allude to: it keeps file replacement to a minimum. You may still want to re-jig the feature tree to keep the self-healing to just the user components: there should be NO HKLM stuff in there at all.

2. Let me think about that. For the time being, I can't see any other way than searching for shortcuts in the user and All Users profiles to the EXE(s) and replacing them if they exist :( You'd probably have to do that in a script-driven CA :( :(
Posted by: kanthsri87 13 years ago
Senior Yellow Belt
0
To Explain breif abt wat VBSCAB told abt "RemoveExistingProducts" it should be there before INSTALL INTIALLIZE COMMAND in your action of sequence.

Hope wen u call this action b4 Install initialize it will remove ur existing product first and then install ur second one perfectly.

This wil sove ur first scenario.

I cant get the second scenario percisely can u pls elabourate
Posted by: pjgeutjens 13 years ago
Red Belt
0
In addition to Ian's responses

1. I've always been apprehensive scheduling upgrades 'late' in the sequence with packages who's feature and component structure changes between versions. I've seen incomplete upgrades due to the fact Windows Installer can't match the old and the new structures. So yes, you're best scheduling early (I believe after InstallValidate is the earliest you can schedule RemoveExistingProducts) to do a complete uninstall right away.

2. You could look into advertising something else besides a shortcut. A class registration or file type association come to mind... they should also allow you to trigger a self-heal as soon as the application starts. The help file of your authoring tool should help you identify the tables that can contain advertisement info besides the Shortcut table.

Rgds,

PJ
Posted by: SandeepPanat 13 years ago
Orange Senior Belt
0
ORIGINAL: kanthsri87

To Explain breif abt wat VBSCAB told abt "RemoveExistingProducts" it should be there before INSTALL INTIALLIZE COMMAND in your action of sequence.


Yes, that would uninstall the previous app and then install new app. But, you may get validation errors related to sequencing of 'RemoveExistingProducts' action.
If you want to follow MS recommendation of placing the action after 'InstallFinalize', you'll have to take care of the component GUID's and make sure they are upgraded properly.

Also, the below comment on msdn by Phil Wilson is worth noting-
The documentation points out the consequences if the uninstall after InstallFinalize fails, but it's worth adding that the rollback of this uninstall is in fact a reinstall of the just-upgraded product. This will leave you with both old and new versions installed, and it seems unlikely that either will actually work in these circumstances. It's safer to do the RemoveExistingProducts between InstallInitialize and InstallFinalize so that it's included in the install transaction, and a failure will leave you with the original product installed.
Posted by: anonymous_9363 13 years ago
Red Belt
0
you may get validation errors related to sequencing of 'RemoveExistingProducts' actionAFAIK, there is no standard validation for the position of the REP action. Thinking about CUB creation (not something I've spent a great deal of time on) is it even possible to trap that?
Posted by: SandeepPanat 13 years ago
Orange Senior Belt
0
ORIGINAL: VBScab

AFAIK, there is no standard validation for the position of the REP action.

Yes, you are correct. There is no standard validation.
(Although - In some rare situations when non-standard authors set REP action even before CostInitialize, the generic ICE27 pops).
Posted by: bos302 13 years ago
Purple Belt
0
Ok. To give an update on my progress...

I've moved the RemoveExistingProducts action to just above..the InstallInitialize action I believe. I'm home now and don't have the MSI handy. But it's working exactly how I hoped.

With the second issue of users accessing the application by means other than the advertised shortcuts, I've put a regkey into the package for an active setup. This is working and will get around the issue, but I'm going to look into the suggestion of using a class registration or something similar. A file extension won't work because they're calling the exe file with no files. Ultimately I'll go with the active setup if necessary, but I'd prefer something neater.
Posted by: kanthsri87 13 years ago
Senior Yellow Belt
0
"The documentation points out the consequences if the uninstall after InstallFinalize fails, but it's worth adding that the rollback of this uninstall is in fact a reinstall of the just-upgraded product. This will leave you with both old and new versions installed, and it seems unlikely that either will actually work in these circumstances. It's safer to do the RemoveExistingProducts between InstallInitialize and InstallFinalize so that it's included in the install transaction, and a failure will leave you with the original product installed".

Hi sandeep it's a Good Quote but still u hav to sequence it before InstallFiles i hope not anywher between Install Iniatize and InstallFinalize
Posted by: anonymous_9363 13 years ago
Red Belt
0
Will active setup be the only answer here? Remember that AS is a one-off hit, executing as it does only the first time that the HKLM and HKCU keys don't match: you don't get self-healing which, if I read right, is a requirement for you.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ