6 replies to this topic

[kamur]

Hello,
We package our software through InstallShield "Full Install" mode. Now this process always takes some time...for a small fix, I end up packaging the full software again....I know there is some method of doing a 'maintenance mode' package only...I want to package only those things which I change every then and often...Could you point to any documentation to do the same...doing 'maintenance release'...? Thanks, Kamur!

[Taco Bell]

I don't follow this approach, but here's an IS article to get started:
http://support.insta...ticleid=Q104431

[kamur]

Hello,

Thanks for the article. I checked with many installshield users...most of the users dont follow this approach...why is this so? Is there any inherent drawback with this approach..
I was thinking to use this method to reduce the packaging time it takes for a small fix..

Thanks
kamur

[Taco Bell]

I can't speak for others, but I personally don't follow it because it's not flexible enough to fit with the my company's distribution of releases and too much overhead for a simple patch.  I also find that the whole "maintenace mode" concept just gets in the way and can make for a unpleasant end user experience.

What I will do for you though is outline my basic approach.

We have the concept of a full install, an update install, and a service pack.  As you might expect, a full is a complete setup which doesn't require a previous version.  An update, on other hand, does require some minimum previous version and will cover any other in between version numbers.  For example, a v1.5 update will work for v1.0 through v1.4 bring them all up to an equivalent v1.5 state. Finally, a service pack will only work on a specific release such as v1.5.1 service pack for v1.5.  Of course, for each of these install types, the size of the setup decreases significantly.

Now that that's out of the way, I'll explain our approach.  To ehance flexibility and ease maintenance, I have a common InstallScript setup.  In that setup, I have a some global variables such as bFull and bServicePack.  I set their values appropriately depending upon the type of setup being developed.  Then, for the real code, I have clauses around the necessary sections such as if (bFull) then, if (!bFull) then, etc.  This allows me to only do those things which are applicable to a release.

In the project, I'll then add, remove, or hide whatever other components/file groups are necessary for the release.

Once having done all that, the basic install is in place, so that just leaves the uninstall process.  This part can be a little tricky, but I think I've found a good process.  First off, by renaming the DisplayName registry values, I hide from the user any old uninstall entries thereby leaving only the latest Add/Remove Program entry intact.  It's job then is to call the auto. generated uninstall routines of its predecessors.  Thereby allowing for complete removal of the product--from v1.5.1 to v1.0.

Obviously these are just the basics of what I do.  There's a lot more to it under the covers.  However, I hope it helps give you an idea for an alternative approach for handling maintenance releases.  Whatever you end up doing though will of course need to be tailored to the needs of you and your company.

[kamur]

Thanks again! I understand what you are saying. But I haven't had much expertise on installshield scripting...If you can provide a sample script for the same or point to similar samples if available online, it would be great to start with....
I really want to develop something in the lines what you are saying..Thanks, Kamur !

[Taco Bell]

It's my own creation, so I don't know of any samples online.  However, I'll see what I can to provide you something.

[kamur]

Thanks, If you can send something to me at kamur@bellsouth.net , it would be great for me to start with..
Thanks again, Kamur!