best practise - optional feature

[wheinsohn]

I am evaluating the InstallShield 2009 Premium and I am wondering how the best practise would be to include a new (but optional) feature. This feature has to copy several files in several folders and adds a few registry entries. Since one component should only contain files from one destination directory, do I have to split the feature in many components or which is the best practise to achive that goal?

best regards,
wheinsohn

[Christopher_Pai]

Components can belong to one or more features. For example if you had a.exe and b.exe that were the main EXE's of two different features and yet they each had a dependency on some common class in c.dll then you'd have

F-A
C-A ( a.exe )
C-C ( c.dll )
F-B
C-B ( b.exe )
C-C ( c.dll )

What you are really trying to ask is how best to componentize your files and registry settings into components which just happen to belong to a new feature. So really this question doesn't have to do with features or optional vs mandatory feature.

Your statemtn of a component having 1 file from one directory isn't entirely correct. While it is true that a component can only install files to 1 directory, the 1 file limitation is meant for EXE, DLL, OCX and so on where it's desireably for the file to be the key file for COM, ShortCut, Advertising, Services and so on reasons. Otherwise a file can have 1 to many `companion files` ( non-keyfiles ) or you can choose to split them up. It all depends on what you want to happen during costing and resilenecy checks. There are multiple best practies ( competing schools of thought ) on this topic.

Regards,
Chris

[wheinsohn]

Thanks for the reply Christopher,

in response to your example with two (optional) features using the same component: how would you implement the setup? I guess the component C-C has to be part of F-A and F-B. Also the GUID for C-C has to be the same in both features. But can you actually add the same component to different feature? So, you have to add them twiece?

kind regards,
wheinsohn

[Christopher_Pai]

Yes, InstallShield/MSI allows you to "associate" a component to multiple features. ( Take a look in the direct editor afterwords and you'll see it's a fake many to many relationship )

Feature <-> FeatureComponents <-> Components
1 to many, many to 1

[wheinsohn]

...but if I take one component from Feature-A and copy (CTRL-drag) it to Feature-B, a new component is created in Feature-B, but lacking the file of the original component and having a new GUID associated with it.

I've tried it in the InstallationDesigner / Organization / SetupDesign Gui. How would you clone the component? Do I have to manually match all fields?

[Kelter]

All you need to do once a component has been created is to right-click a feature in the Setup Design view, and select "Associate Components." A dialog box will pop up and allow you to select the components you'd like to associate with the current feature.

The concepts are hierarchical.

Think of it this way: Components contain Files, reg entries, settings, etc that belong together in an atomic manner (they should never be seperated.) Features contain components and other features.

As a corollary, components contain files with the same destinations and conditions. They shouldn't contain more than one executable file, especially if you want your "Repair" functionality to work. If one file needs to be placed in more than one location on the target machine (unusual scenario) that same source file can belong to more than one component. If a component needs to be installed when at least one of a set of features is selected, then said component should be associated with each of those features. And lastly, if a feature depends on one other feature, it should be a subfeature of that feature.

[wheinsohn]

Thanks, this works. It would be nice if the CTRL-drag would do the same. In my opinion that would be a logical application behaviour.

[Kelter]

In my opinion, if you type a long string with some sytax error somewhere in it, and hit [enter], it shouldn't clear the whole field and make you retype the whole danged thing, but these little details are not as important as adding functionality and fixing bugs that people have been ranting about for several versions.

Ctrl+drag or copy and paste would be really useful elsewhere too, (reg view) but alas, the bussiness of installation development is a tedious one indeed. Good luck!

PS: I've authored an installation involving around 300 components, and a really large number of them were for individual executables. This would have been just file except for the fact that these executables had our own file extensions, so IS couldn't just let me grab a whole directory full of them, and let the component wizard create individual components (as it would if they were all .exes or .dlls.) As a result, I spent a few days doing something that could otherwise have taken a couple hours. Maybe our desired features will make it into IS 2010 or something. 😛

[DebbieL]

Kelter,

Have you tried adding your own special file extensions to the box on the File Extensions tab of the Options dialog box (Tools menu > Options > File Extensions tab)? This is new for InstallShield 2009. The Component Wizard creates new components for every file that has one of the file extensions listed here.

Here's a help topic that describes a few more details:
File Extensions Tab

[Kelter]

That would have been useful a year and a half ago when I authored the thing in the first place. 😛 Very good to know for the next project I start, however!

These features do creep in over time. I guess i wasn't the only one looking for that. Boy, oh boy! dynamic directories would have made the last year and a half of my life soooo much easier!