For Active Setup, Application repairing is taking huge time
Hi,
I am currently repackaging an internal application. Its size is 8.47 GB and its putting resources at user location. NO Advertise shortcut.
So for that I am using Active Setup and it working fine...As this application is very huge, for repair it’s taking huge time.
Is there any way can I reduce its repair time (is there any methods in Active setup or any other way I can repair only that particular feature having user location resource instead of entire application for repair)
Thank you in Advance!!!!
Raj Sam
Answers (5)
What is the StubPath value of your Active Setup key
Comments:
-
"StubPath"="msiexec.exe /fpu [ProductCode] /qb!" - RajSam 11 years ago
You need to create a new feature, put your active setup component and all other current user components into this feature. this will repair this feature only and greatly reduce your repair time.
Comments:
-
oreillyr, thanks for the reply.I think it will work...But problem is ,there are 7 features having resources going to user location and lots of files and reg(around 800) then i have to move.it is really taking huge time..is there any other method?or vb script. - RajSam 11 years ago
-
Again if I am moving all the user location resource to a new feature ,it may create problem for upgrade of the application in future. - RajSam 11 years ago
-
- oreillyr 11 years ago
Why would you believe that a) using VBScript or some other method would be faster than native Windows APIs (which is what AS uses), and b) that creating a proper feature structure would create problems for upgrades? Any upgrade package would surely use this first one as a base, since you need to keep features etc. aligned (see MSDN for details of what constitutes the various forms of Windows Installer upgrades)
VBScab is pretty much right... Though some MSI can take a long time to evaluate keyfiles/entries etc taking much longer then a VBS might. Noticable at long delays at gathering info... I have seen apps that do this but not enough to figure out why it takes forever...
If you are given an MSI, the first option should ALWAYS be MSI rather then a script. I avoid scripts like the plaque unless I can't do it with MSI logic.
For improving msi self-repair/healing, this thread is VERY informative... http://www.itninja.com/question/self-heal-for-install-shield-msi#24172
As for upgrade concerns... if you are in a managed environment you should be the one doing the customization on the upgrade and testing against your previous deployment. Therefore the only mistakes you can make is if they truely are not upgradeable (never ran into this problem before in years of packaging). Even then you can run a 2 step upgrade, uninstall old and install new. Most cases you should look at your packaging docs (you do keep notes on what you did and why right?) on the previous versions and perform very similar changes to the new upgrade.
If you are really set on not using msi repair (don't know why), then I would advise you to test what happens if you don't use active setup and run the app... How many/much of the per user data is created by the app (many apps do this), what isn't etc. Then create a solution for ONLY the critical data the app doesn't recreate at runtime... heck this is even good advice if you are planning on using msi repair.
