best practice violation: 1 EXE per component? why? 1 main .EXE + 20-30 support EXEs!!!

[Alastair Cameron]

Our main application product EXE (a GUI data warehousing application) has
about 20-30 additional support .EXEs (these are associated command line
tools for doing various things such as loading data, etc).

I am packaging the application install using ISWI, and I wanted to create a
windows installer component for the main product. However, the 20-30 support
EXEs really belong in the same component as main EXE - it seems massive
overkill to put each of these in their own component, especially as they are
so tied to the main product .EXE.

However If I put them all in the same component, I will be in violation of
the Windows 2000/ISWI best practices.

I'm not sure of the repercussions of doing this;

Would anybody like to comment on why, based on the scenario I have
described, each of the EXEs should be in their own component (or not as the
case may be).

Thanks.

Alastair

[Rene]

Hi Alastair,

If you do put them all in one component you will not encounter any problems
during install. But when you try to install a newer version of one of your
tools (next version of your product), the windows installer engine will only
check for the version of keyfile of the component. So if you make tool1.exe
the keyfile, and you upgrade tool2.exe (which is in the same component),
Windows Installer will not think that the component is a newer version, and
not install the new tool2.exe, since it only checks the version of
tool1.exe. Worse: in the same way newer versions can be overwritten by older
ones. (It's the only way to force Windows Installer to overwrite older
versions, so this violation sometimes has to be made on purpose.)

In general, you shouldn't be too worried about best practice violations,
most installations do violate some of them.

You could post further questions in fewer groups ;)

Kind regards,

Rene
"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:3b67...@news.installshield.com...

[Alastair Cameron]

Rene,

Thanks for the help. Your comments help.

"Rene" <re...@no.mail> wrote in message news:3b67c051$1...@naarden.PDS...

[Phil Wilson]

Repair works on the key file, so if you have lot of files in a component and
some of them get removed but NOT the key file, Repair won't install the
missing ones because the key file is still there.

Let's say that one day you'd like to have an inventory of all the installed
files. So you write some code (like a VBScript) that iterates through all
your installed components so you can report all their versions on the system
(Installer.ComponentPath then Installer.FileVersion). Oops, you can't,
because you can see only the key file of the component and not the rest.
Those other files in the component are effectively invisible to the
installer APIs.

"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:3b67...@news.installshield.com...

[Michael Scribano]

Perhaps a change of perception would help:

By creating a separate component for each EXE file, greater control is given
to the Installer in its handling of the object. Each file is stuffed inside
a component wrapper which providing low-level properties that are useful for
handling a variety of situations. For example, setting conditions on
individual files is very useful.

Your current idea of a component is really a Feature. It is at this level
that you have the ability to lump related components (your EXEs) together as
the project dictates. From here, of course, sub-features can also be
created to give a project even more control, if needed.

-Mike

"Alastair Cameron" <alastair...@blueyonder.co.uk> wrote in message
news:3b67...@news.installshield.com...