Scripting Question

For Active Setup, Application repairing is taking huge time

11/29/2012 2315 views


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

0 Comments   [ + ] Show comments


Community Chosen Answer


What is the StubPath value of your Active Setup key

Answered 11/30/2012 by: jagadeish
Red Belt

  • "StubPath"="msiexec.exe /fpu [ProductCode] /qb!"

All Answers

This content is currently hidden from public view.
Reason: Removed by member request For more information, visit our FAQ's.

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.

Answered 11/29/2012 by: oreillyr
Fifth Degree Brown Belt

  • 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.
    • 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.

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)

Answered 11/30/2012 by: VBScab
Red Belt


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.

Answered 12/03/2012 by: dandirk
Third Degree Green Belt

  • This content is currently hidden from public view.
    Reason: Removed by member request For more information, visit our FAQ's.

thank u guys for input

Answered 12/04/2012 by: RajSam
Yellow Belt

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