3 replies to this topic

[Becky Nichols]

It seems I've read something about using one installation to create "different flavors" of an installation.  

We have two products that require all the same files, except the Application files (one file group is different).  I have been thinking I can add both application file groups to one installation, then use the "Include in Build" option to select which one to use.  Then I saw the "replace GUID" on this site.

I guess what I'm asking is:  Is anyone doing this?  Does it sound like I'm on the right path?  It would be much easier then maintaining two installation projects just for one file group differenct.

Thanks for any input you might have.

Becky

[Taco Bell]

I do something like this with some of our products.

We have both an update and full install available for one of them.  Since the two file groups are grossly different, I have two separate projects, but I use the same code.  The only difference between the two  setup.rul files is the assignment of bFull to be false for the update and true for the full install.  I then have subsequent checks within the code to do one thing or the other depending upon which scenario I'm in.  This has worked quite well.

Another version of this same product has both a keyed and non-keyed full install.  This one's more like your situation as they are only different in their applications.  Since I want the two to have the same GUID, I use the same project and just manually change the included file groups.  As before, I also have a bKeyed which lets me know which context I'm in.  Finally I have two different media definitions so as to not overwrite them and to help manage which is which.  In time I thought about creating additional ghost components for these file groups which I would include or exclude automatically through the code depending upon the value of bKeyed.

Another way to ease maintenance, which I haven't gotten into yet, is to create common code and use the #include functionality to make it available.  You can make it more versatile by expanding the paramaters that these functions take and the like.

Hope it helps.

[Becky Nichols]

Thanks for your reply.  I have already used the "common code" method with the #include.  Now my project setup.rul file is just a shell that calls code in a common file.  So the two projects share the script code.  I was looking to ease the duplication on all the rest, such as the registry entries, shortcuts, etc.

Think I'll try the two application file groups approach and the change in the GUID so they go on the machine as separate installations.

It's worth a try.

Thanks again.

Becky

[Taco Bell]

I was looking at the IS feature list and another method came to mind.  Here's there description of it:

"NEW! Release Management

Select the components to include in each release via the Media Wizard, allowing different CDs to contain different components. Allows one project to easily build several flavors or versions of a product."

It would still take some management on the part of the script since you'd still need to control which components were listed, but it's something else to consider.