Concepts for combined installers

[Sebastian P.R. Gingter]

Hello,

I have a question especially for those who have experience with these kind of things.

I want / need to build an installer for an application that has several dependencies.

On the lowest level there are some device drivers (these come with a separate installer that can be called and installed silently), then there are some windows services that communicate with these drivers which come either with a separate installer too, or as a xcopy deployment where we need to register the service manually.

Also, depending on the target environment, it is one out of three possible device drivers and also one out of two possible services. Which driver goes with what service is fixed, so a selection of a specific driver (for a specific hardware device) will require a certain service and disallow installation of the other.

Lastly its the application to install. Some parts also needs some configuration (some values need to be written in some files). So we can either ask the person installing for the values in GUI, or pass them as command line args.

When the application already is installed, the setup should be un-doable in case something gets wrong with an update. So there needs to be a way to restore to the previous version. We can use a file-based backup in beforeinstall for the xcopy services and the application, I still need to figure out what can be done with the drivers.

Additionally to the installation, there should also be some way for a bit of configuration for all components. I know that the Git for Windows installer also allows even conditional configuration (only configure stuff that's not yet configured), which is a feature I love. Need to check out how they did that.

Lastly, the parts are versioned individually. So there might be only an updated service, and we would build a new combined setup only with that new service, and when installed it should ideally only update the single service that changed, and not touch the other components. Also in case of an issue, only this single service update should be un-doable.

Except for the undo-part I know that all of this, in theory, should be possible somehow, but for example for the execution of other embedded installers I found several ways to achieve this, some of them use tasks, some use afterInstall (I don't like that, as the application should not install before the dependencies aren't properly installed). 

After all, there seem to be a LOT of possible ways to achieve this.

Now my question is, what are the suggested / best approaches to such a complex installation scenario? Also, is there a suggested approach to take on such a project? Are there any best practices you can suggest? I want to come out of this with a maintainable installer that is more or less foolproof to use (for most degrees of fool ;) ).

The main reason for this project is to provide a single installer for customers to be able to setup the whole thing by themselves. The current way is that a support agent remotely installs all parts manually, because the customer can't (or shouldn't) be bothered with all the parts of this complex installation.

Thanks for your suggestions,

    Sebastian

[Bill Stewart]

On Thursday, April 22, 2021 at 9:45:34 AM UTC-6 Sebastian P.R. Gingter wrote:

I have a question especially for those who have experience with these kind of things.

I want / need to build an installer for an application that has several dependencies.

............

TL;DR. Just being honest.

Try asking one specific question at a time.

Bill

[Sebastian Gingter]

This is one question.

I was just giving context.

Most times it's problematic when people ask X and then get A as an answer, because they simply forgot to mention the requirement Y and then B would be a better answer.

So I try to prevent that by giving as detailed a context as I can.

Cheers,

  Sebastian

--
You received this message because you are subscribed to a topic in the Google Groups "innosetup" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/innosetup/2BMG4zx-wpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to innosetup+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/innosetup/c8971893-7810-454e-91c7-bb8d251641c6n%40googlegroups.com.

[Gavin Lambert]

On 23/04/2021 4:56 pm, Sebastian Gingter wrote:
> This is one question.

"What is the best way to do these 20 things?" might technically be one
question, but it's a complicated one. :P


Recommended practice with Inno is to have one installer with all {app}
files marked with "ignoreversion" (different recommendations apply to
shared components installed elsewhere, but those are unfashionable these
days).

This means that it will unconditionally overwrite the existing files
with the ones in the installer. Most of the time, this means that your
"rollback" process doesn't require any backups, you just keep a copy of
the previous version's installer and run it again.

(There are caveats; for example if your app updates some documents, data
files, or settings then the older version may not be able to understand
them any more. If there's a well-defined set of files then you may be
able to have some kind of backup solution for that, but otherwise you
can't really support rollback.)

If you want to have optional components then you can use one install
script with [Components]. This lets the user choose when to install
them, but once installed they're best off always upgrading them -- they
can't uninstall a component once it's installed.

If you want to be able to uninstall components individually then you
have to make separate install scripts with separate AppIds, although you
can then wrap these up into a parent install script which simply runs
them. Usually this parent script does nothing else but run them (and is
either itself not uninstallable, or running its uninstaller just
triggers uninstall of all the components).

More complex scenarios are possible, but require more complex code (and
testing) investment.

[Martijn Laan]

Op 22-4-2021 om 17:45 schreef Sebastian P.R. Gingter:

the application should not install before the dependencies aren't properly installed

Take a look at the CodePrepareToInstall.iss example script.

Greetings,
Martijn Laan