[Mono-dev] Win32 Gtk# Installers (Was: Re: C bindings VS C++ bindings (Gtk# vs. Kimono?))

[Brad Taylor]

On Tue, 2007-10-16 at 13:51 -0500, Jerome Haltom wrote:
> You misunderstand how merge modules work.

At this point, my knowledge about this whole MSI thing is just slightly
above zero, and I've found the MS documentation to be incredibly lean on
more complicated install practices, so you're most likely correct.

> Merge modules, when included in another package, lose their identity.
> They cannot install files which are shared by other packages. They can
> not be versioned against each other.

Sadly this is the case, but it's no different than how we operate
currently with every installer (Medsphere, Mono, Pidgin, etc) bringing
in their own version of Gtk+, Gtk# and friends.

It would be great if there was a better solution, but the main focus of
merge modules *for Medsphere and Novell/Mono* is to share the
maintenance responsibilities for developing installers.  If this whole
thing works out, Medsphere will be maintaining a Gtk+ merge module, and
Novell would maintain the Gtk# one.  Then, Novell and Medsphere will
build their own installers that bring in the modules that they want
without duplicating tons of effort.

<snip>

> Microsoft recommends that you create a .msi file for each primary
> distributable (Gtk, Gtk#, Mono, etc) and have the application
> distributor build a bootstrapper which references these .msi files
> independently. VS2005 has a setup project built in which does this: it
> automatically generates a bootstrapper that installs .Net itself.

Interesting -- I'll look into this approach.

-Brad