5 replies to this topic

[Mr.B]

Hello All

I have a little design problem while trying to create the install for my application.
I want my installation to contain some packages ( e.g. App1 , App2 and App3)
and when user installs it he can choose from a Dialog the kit he likes to install.

I tried doing so with 3 MSMs but i cannot use conditions on them !

Maybe someone know what is the best and correct way of doing so ....


Thanks a lot

[Stefan Krueger]

You can make 3 features, one for each app.

[Mr.B]

Thanks ...

But still i donno how to add a feature.
I am using orca to add new line for each feartue in the feature Table.
but how to i link between the feature to the MSM
and what values should i write in the feaute table

Thanks again

[rgraham]

Sorry if this seems simplistic, but..

Defining "Features" is simple. The tric is understanding the key relationships between features and other tables.

First you need to understand the MSI high level view of an install.

At one end you have "features" - This is the highest level view and represents entities that are meaningful to the user.

For example, an MS Office install would present some high level features to the user, i.e. "Word", "Access", "Excel". The user can pick what he wants. Maybe he wants Word and Excel, but not Access.

This is how you organize your install from the perspective of "features".

At the other end of the spectrum lies resources (files being the most intuitive one). Each feature requires certain files to be installed on the target machine.

Now comes the tricky part - Components. Suppose your 3 apps all require completely different files. You can organize the files for each of the 3 "features" into 3 components, each of which contains the group of files required for the specific feature.

But now suppose your 3 apps all share use of a custom control, which requires several files. In this case, you need a fourth component that encapsulates the custom control files, and is installed when any of the 3 features are selected. This also ensures integrity. Suppose your user installs all 3 features, but later uninstalls one. The other two still need the custom component. So this is why you organize the custom control files into a separate component that is installed for any of the 3 features, but is also only uninstalled if and only if all 3 features are uninstalled.

Once you understand the basic principles of how an MSI should be organized into Features, Components, and Files, it makes it simpler to understand exactly how the various tables are related.

I know that does not explain the specifics. Developing an install with Orca is tedious and difficult.

But the first step is mapping out the file requirements of each of your features, then organizing them into components. Once you've done that, it make sit much more feasible to understand required entries in tables, how to set attributes, and how the tables ultimately correlate with the application image created by your install...

Robet

[Mr.B]

Thanks Robert but i understood this concept earlier !

But , I still donno how to add the feature to the MSI.
should I do it via .NET or just with ORCA ??

I tried Orca but there ate too many tables there ...
I went to the feature table and tried to add a line
but I donno what each column means and needs to be set.
and how to tell the MSM that it relates to the feature or the opposite way.
and how do I create the condition ???

Please Anyone ???


Thanks again

[Stefan Krueger]

For a list of MSI authoring tools see http://www.installsi...g/go/msidev.htm
I wouldn't recommend starting a setup project from scratch using Orca.