4 replies to this topic

[p13]

I'm trying to create a program that will allow a user to select some product features/components and the program will then grab the files for those features and generate a MSI install using the MSI API.

Does anyone think there's a better way to create dynamic installs? I need some sort of dynamic install because some clients will want to install only a portion of the product with theirs while others may want the whole thing.

I was also wondering if anyone might know how much work it would take to generate a MSI vs a MSM. Is it wrong to assume that it is just removing a few tables from the MSI database and adding a couple for the MSM?

[Zweitze]

If you want to empower administrators to manipulate the setup that end users will experience, you should look into transforms, the official way to go. I believe MS Office uses this approach to allow admins to modify the setup for their end-users.
I once used a different direction for the same result, by modifying the Administrative setup. Using some custom dialogs admins could enter certain information like licensing, the resulting setup then wouldn't ask this info from end users.

About MSM vs MSI: one difference I can think of is the location of the files. In an MSI, you have three options: separate to allow Run From Source, in a CAB file, and in the MSI file. In an MSM, you have one option: in the MSM.

[p13]

I'm not trying to empower administrators, but rather allow other software developers that bundle our product with theirs to control the size of our install.

They may only want to bundle a small component with their product and don't want the extra 150 megs of our product.

Am I wrong to think that a Transform cannot create a new install and can only be applied to a MSI during installation?

[Zweitze]

In that case:
Create and distribute Merge Modules. Create multiple MSMs, for each feature.

A program that generates complete MSIs is not a good solution, because such programs force developers to use only that program, developers can not use software like Wise, InstallShield for their setups.

An alternative is creating an MSI and telling the developers to install it as a child setup: this also works for developers that use non-MSI installs.

BTW You were right about transforms.

[duncanl]

I've been developing something that might be appropriate (or might not)

We have standard installers for a variety of product types and via a standard set of tools (ie an exe and a data file) we populate the installer with the project team's files etc. They then have a customised installer. Obviously MSMs can be generate instead if the files are common to multiple projects.

The same idea is used on customer sites to allow them to generate their own version of a standard product installer, from a base msi, but with their own custom files and settings.

MSTs are also used to update the base msi at customer sites with updates / fixes etc and can be embedded, so do not need to be run always - this does depend on what you need the MST to do.

Which is basically goes against....

Zweitze wrote:
"A program that generates complete MSIs is not a good solution, because such programs force developers to use only that program, developers can not use software like Wise, InstallShield for their setups."

InstallShield (and I guess Wise) will allow you edit existing msi's so it is a solution - but I see your point / caveat.

Obviously it is a solution, within certain constraints, but allows project teams to create a fully-fledged production installer - either with msms only or a combination of files & msm.

This aids developers / project teams that do not have a dedicated msi developer.