I guess my problem is very similar, i.e. includes the one mentioned above...
I'm struggling with a forthcoming a product which has three optional
components. It is OK to have a single installation containing these as
different features. In reality we should obtain packages combining
these three components, say a package for component1 and component2, a
standalone package for component3, and another msi which contains all of
them, each one as a different feature. Currently I have three different
"main" wxs files matching the three packages, a wxi include for defines like
ProductID, CompanyName etc., and the three features isolated into three
fragments, referred to in different combinations from the "main" files.
(This way the complaints for the duplicate symbols are eliminated.) I'm
still unsure whether it is done the recommended way or not. Perhaps it turns
out from the following lines, why.
My real problem arises when it comes to switching from one kind of
installation to another.
I would like to see the full installer seamlessly extend e.g. the installed
component3 to a full installation. On the other hand, the MSI containing
component1 and component2 should extend an installation of component3 to a
full installation. There is no 'hierarchy' in the installation (there is no
ordering, so I think I should not use updates/upgrades to solve this issue),
and I'd like to have a least confusing GUI, without e.g. disabled features,
but still based on the wixui lib as far as possible. Having the same package
ID "confuses" the MSI installer, it is clear from the tutorial that this
situation should be avoided, but having different package IDs leads to
"Another version of the product is already installed...".
Can this kind of upgrading/extending be accomplished (I think so), and how?
2007/9/13, Rob Hamflett <[EMAIL PROTECTED]>:
>
> I think you'd better off using Fragments and using *Ref elements.
>
> Rob
>
> Jared Hughes wrote:
> > My group is producing two products: a Runtime and an SDK. Since there is
> a
> > lot of similarity between the two products (a lot of the same files, reg
> > keys, shortcuts, custom actions, etc) there is a push to get everything
> > unified into a single file that should, in theory, be easy to maintain.
> Is
> > it possible to do this? I've tried moving a lot of the common components
> > into a separate file which is then included with an <?include?>
> statement,
> > but I get error messages about duplicate symbols for, say, my program
> files
> > directory or my TARGETDIR directory. Am I overlooking something
> > straightforward here or would it be best to maintain separate files for
> the
> > Runtime and the SDK?
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
