Installation for a product suite

Y

YDSAN

Hi,
I need to come up with an installation for a product suite. The installation
needs to display a set of general screens
such as welcome, license etc. After this each of the individual product
installations need to be launched. Which is the
best way to package these applications ? Should there be a single MSI file
or should I have separate MSI files
for each product ?
Regards,
Sandhya
 
P

Phil Wilson

My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier in the
sense that you're updating/patching one MSI file instead of several.
 
Y

YDSAN

Hi,

Since the features do not have GUID, how can I detect the presence of the a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


Phil Wilson said:
My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier in the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
Hi,
I need to come up with an installation for a product suite. The installation
needs to display a set of general screens
such as welcome, license etc. After this each of the individual product
installations need to be launched. Which is the
best way to package these applications ? Should there be a single MSI file
or should I have separate MSI files
for each product ?
Regards,
Sandhya
 
P

Phil Wilson

MSI knows the state of the features and components installed with a product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
Hi,

Since the features do not have GUID, how can I detect the presence of the a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


Phil Wilson said:
My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier in the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
 
Y

YDSAN

That is clear to me now.

The products suite I need to package has 15 products. There are a total of
500 packages- these are like features.
Some of them are common packages which are shared across all the products.
The number components is really huge.
The products are interdependent on each other. The main installation program
has to display
a selection screen for the products and when the user selects the products,
the dependent products need to be
installed automatically in the correct order. This dependency information
will be provided. The installer has to process
the same.
Each of these products have configuration also. Patching is required. Silent
installation is also required.

Can you give some tips for design of such a complex system.

I am mainly looking for help in the following areas:

1. One MSI VS multiple MSI (You already answered this; but you may advise
as per the requirements above)
2. The mapping of product-feature-component. Is it possible to have sub
features in MSI ?
3. Design of user interface - Lot of custom dialogs may be required. How
difficult is it to implement the UI
4. How can other Java/C++ modules interface with MSI ? This is basically to
feed the dependency information to MSI
5. Will it be possible to build in the dependency information in the MSI
itself ?
6. Any other general guidelines

Thanks and regards



Phil Wilson said:
MSI knows the state of the features and components installed with a product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
Hi,

Since the features do not have GUID, how can I detect the presence of
the
a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


Phil Wilson said:
My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier
in
the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
 
P

Phil Wilson

If you want multiple features or sub-features and custom dialogs, Visual
Studio won't do it. Take a look at these choices:
http://installsite.org/pages/en/msi/authoring.htm

If the products are dependent on previously installed products, you can't
really use a single MSI file because in a single MSI file everything gets
installed at once. If all the dependencies don't have much visible effect on
the system, look at organizing all these products so that all the
dependencies are in one MSI file that you always install, then everything
else could be an one other MSI file using features and sub-features. That's
the Microsoft model - dependencies like MDAC, .NET framework are installed
first and separately, then you install the products that use them.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
That is clear to me now.

The products suite I need to package has 15 products. There are a total of
500 packages- these are like features.
Some of them are common packages which are shared across all the products.
The number components is really huge.
The products are interdependent on each other. The main installation program
has to display
a selection screen for the products and when the user selects the products,
the dependent products need to be
installed automatically in the correct order. This dependency information
will be provided. The installer has to process
the same.
Each of these products have configuration also. Patching is required. Silent
installation is also required.

Can you give some tips for design of such a complex system.

I am mainly looking for help in the following areas:

1. One MSI VS multiple MSI (You already answered this; but you may advise
as per the requirements above)
2. The mapping of product-feature-component. Is it possible to have sub
features in MSI ?
3. Design of user interface - Lot of custom dialogs may be required. How
difficult is it to implement the UI
4. How can other Java/C++ modules interface with MSI ? This is basically to
feed the dependency information to MSI
5. Will it be possible to build in the dependency information in the MSI
itself ?
6. Any other general guidelines

Thanks and regards



Phil Wilson said:
MSI knows the state of the features and components installed with a product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
YDSAN said:
Hi,

Since the features do not have GUID, how can I detect the presence of
the
a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier in
the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
 
Y

YDSAN

Thank you Phil. I will look into the tools.
Packaging all the dependant components in one MSI is a good idea.
In case of features and sub features, it will be good to have one MSI
since I can get the details required for displaying the list of features and
sub features
from the same MSI file.
At the same time I want to package the sub features and components related
to
one feature in a separate unit. Can this be a MSM file ? How can I link it
to the main MSI file ?

Thanks and Regards


Phil Wilson said:
If you want multiple features or sub-features and custom dialogs, Visual
Studio won't do it. Take a look at these choices:
http://installsite.org/pages/en/msi/authoring.htm

If the products are dependent on previously installed products, you can't
really use a single MSI file because in a single MSI file everything gets
installed at once. If all the dependencies don't have much visible effect on
the system, look at organizing all these products so that all the
dependencies are in one MSI file that you always install, then everything
else could be an one other MSI file using features and sub-features. That's
the Microsoft model - dependencies like MDAC, .NET framework are installed
first and separately, then you install the products that use them.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
That is clear to me now.

The products suite I need to package has 15 products. There are a total of
500 packages- these are like features.
Some of them are common packages which are shared across all the products.
The number components is really huge.
The products are interdependent on each other. The main installation program
has to display
a selection screen for the products and when the user selects the products,
the dependent products need to be
installed automatically in the correct order. This dependency information
will be provided. The installer has to process
the same.
Each of these products have configuration also. Patching is required. Silent
installation is also required.

Can you give some tips for design of such a complex system.

I am mainly looking for help in the following areas:

1. One MSI VS multiple MSI (You already answered this; but you may advise
as per the requirements above)
2. The mapping of product-feature-component. Is it possible to have sub
features in MSI ?
3. Design of user interface - Lot of custom dialogs may be required. How
difficult is it to implement the UI
4. How can other Java/C++ modules interface with MSI ? This is basically to
feed the dependency information to MSI
5. Will it be possible to build in the dependency information in the MSI
itself ?
6. Any other general guidelines

Thanks and regards



Phil Wilson said:
MSI knows the state of the features and components installed with a product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
Hi,

Since the features do not have GUID, how can I detect the presence
of
the
a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is
easier
in
the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
single
MSI
 
Y

YDSAN

Thank you Phil. I will look into the tools.
Packaging all the dependant components in one MSI is a good idea.
In case of features and sub features, it will be good to have one MSI
since I can get the details required for displaying the list of features and
sub features
from the same MSI file.
At the same time I want to package the sub features and components related
to
one feature in a separate unit. Can this be a MSM file ? How can I link it
to the main MSI file ?

Thanks and Regards


Phil Wilson said:
If you want multiple features or sub-features and custom dialogs, Visual
Studio won't do it. Take a look at these choices:
http://installsite.org/pages/en/msi/authoring.htm

If the products are dependent on previously installed products, you can't
really use a single MSI file because in a single MSI file everything gets
installed at once. If all the dependencies don't have much visible effect on
the system, look at organizing all these products so that all the
dependencies are in one MSI file that you always install, then everything
else could be an one other MSI file using features and sub-features. That's
the Microsoft model - dependencies like MDAC, .NET framework are installed
first and separately, then you install the products that use them.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
That is clear to me now.

The products suite I need to package has 15 products. There are a total of
500 packages- these are like features.
Some of them are common packages which are shared across all the products.
The number components is really huge.
The products are interdependent on each other. The main installation program
has to display
a selection screen for the products and when the user selects the products,
the dependent products need to be
installed automatically in the correct order. This dependency information
will be provided. The installer has to process
the same.
Each of these products have configuration also. Patching is required. Silent
installation is also required.

Can you give some tips for design of such a complex system.

I am mainly looking for help in the following areas:

1. One MSI VS multiple MSI (You already answered this; but you may advise
as per the requirements above)
2. The mapping of product-feature-component. Is it possible to have sub
features in MSI ?
3. Design of user interface - Lot of custom dialogs may be required. How
difficult is it to implement the UI
4. How can other Java/C++ modules interface with MSI ? This is basically to
feed the dependency information to MSI
5. Will it be possible to build in the dependency information in the MSI
itself ?
6. Any other general guidelines

Thanks and regards



Phil Wilson said:
MSI knows the state of the features and components installed with a product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
Hi,

Since the features do not have GUID, how can I detect the presence
of
the
a
particular feature on a system ?
If the user has installed one of the features (one product in this case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


My preference is for a single MSI file where the "products" are in fact
features. If the user wants to add or remove features, you've got the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is
easier
in
the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
single
MSI
 
P

Phil Wilson

You can build parts of the setup as merge modules. The majority of the tools
let you build merge modules and add them to MSI projects.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760

YDSAN said:
Thank you Phil. I will look into the tools.
Packaging all the dependant components in one MSI is a good idea.
In case of features and sub features, it will be good to have one MSI
since I can get the details required for displaying the list of features and
sub features
from the same MSI file.
At the same time I want to package the sub features and components related
to
one feature in a separate unit. Can this be a MSM file ? How can I link it
to the main MSI file ?

Thanks and Regards


Phil Wilson said:
If you want multiple features or sub-features and custom dialogs, Visual
Studio won't do it. Take a look at these choices:
http://installsite.org/pages/en/msi/authoring.htm

If the products are dependent on previously installed products, you can't
really use a single MSI file because in a single MSI file everything gets
installed at once. If all the dependencies don't have much visible
effect
on
the system, look at organizing all these products so that all the
dependencies are in one MSI file that you always install, then everything
else could be an one other MSI file using features and sub-features. That's
the Microsoft model - dependencies like MDAC, .NET framework are installed
first and separately, then you install the products that use them.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760 total
of
500 packages- these are like features.
Some of them are common packages which are shared across all the products.
The number components is really huge.
The products are interdependent on each other. The main installation program
has to display
a selection screen for the products and when the user selects the products,
the dependent products need to be
installed automatically in the correct order. This dependency information
will be provided. The installer has to process
the same.
Each of these products have configuration also. Patching is required. Silent
installation is also required.

Can you give some tips for design of such a complex system.

I am mainly looking for help in the following areas:

1. One MSI VS multiple MSI (You already answered this; but you may advise
as per the requirements above)
2. The mapping of product-feature-component. Is it possible to have sub
features in MSI ?
3. Design of user interface - Lot of custom dialogs may be required. How
difficult is it to implement the UI
4. How can other Java/C++ modules interface with MSI ? This is
basically
to
feed the dependency information to MSI
5. Will it be possible to build in the dependency information in the MSI
itself ?
6. Any other general guidelines

Thanks and regards



MSI knows the state of the features and components installed with a
product.
What are you thinking about that caused you to ask that question?
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
Hi,

Since the features do not have GUID, how can I detect the presence of
the
a
particular feature on a system ?
If the user has installed one of the features (one product in this
case),
next time the installation is launched,
can MSI detect that the feature has already been installed ?

Regards


My preference is for a single MSI file where the "products" are in
fact
features. If the user wants to add or remove features, you've
got
the
built-in dialog for feature selection (otherwise you're
installing/uninstalling another MSI file), and maintenance is easier
in
the
sense that you're updating/patching one MSI file instead of several.
--
Phil Wilson
[MVP Windows Installer]
Definitive Guide to Windows Installer
http://www.amazon.com/exec/obidos/tg/detail/-/1590592972/104-7044380-4696760
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top