Windows Installer XML (WiX) toolset › wix-users

How to best install generic system with customer specific add-ins

8 messages

How to best install generic system with customer specific add-ins

Reply Threaded

I am currently finishing up on a generic system which we will sell to
many different customer with different needs. So, as a result this
generic system is based on extensions, or add-ins.

Now I am thinking how to best write an installer for this.
Although I could copy-n-paste the entire WiX project every time I make a
new customer-specific extension, I think that is quite the wrong way to
go about writing the installer for this system.

So, I am thinking patches, or maybe transformations?

An installer for the system itself, and then a patch with the customer
specific bits. This way, I get to maintain a single installer with
upgrade codes etc. and a simple patch installer for each customer
project. On paper that should be simple enough, but how do I do that?

I am currently still learning WiX, so my knowledge is, at best, shaky.
So I need a bit of help.

How do I create patches for a specific installer, and is the plan
actually sound?

Best regards,
Thomas Due - Software Developer

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Thomas Due

Re: How to best install generic system with customerspecific add-ins

Reply Threaded

I have been studying the documentation and the tutorial and come to the
conclusion that patching is out, since that is essentially just the
difference between two installers which is exactly what I want to avoid;
Writing two installers...

So, my next thought is: How about merge modules then?

What I mean is, that I put all the common stuff into a merge module, it
seems that it can contain all the logic regarding files and components
and installing/starting services etc.

Then I write the installer for each customer, which contains only the
customer specific bits and adds the merge module containing all the
common bit etc.

So far so good. But how about the UI? Can I contain MOST of the gui in
the merge module and only add a few customer specific dialogs (if
necessary) in the customer installer, and if so, how do inject dialogs
like that?

Best regards,
Thomas Due - Software Developer

-----Original Message-----
From: Thomas Due
Sent: 22. oktober 2009 09:13
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to best install generic system with
customerspecific add-ins

I am currently finishing up on a generic system which we will sell to
many different customer with different needs. So, as a result this
generic system is based on extensions, or add-ins.

Now I am thinking how to best write an installer for this.
Although I could copy-n-paste the entire WiX project every time I make a
new customer-specific extension, I think that is quite the wrong way to
go about writing the installer for this system.

So, I am thinking patches, or maybe transformations?

An installer for the system itself, and then a patch with the customer
specific bits. This way, I get to maintain a single installer with
upgrade codes etc. and a simple patch installer for each customer
project. On paper that should be simple enough, but how do I do that?

I am currently still learning WiX, so my knowledge is, at best, shaky.
So I need a bit of help.

How do I create patches for a specific installer, and is the plan
actually sound?

Best regards,
Thomas Due - Software Developer

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Rob Mensching-7

Re: How to best install generic system with customerspecific add-ins

Reply Threaded

If Merge Modules look like they will work, I'd use .wixlibs instead (
http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them).
The WiX toolset's reusable functionality (from the Extensions and all the
UI) use .wixlibs. The Wix.chm has a nice section on how to customize
dialogs. I'd start there. Without more details about your exact project
it's hard to provide more detailed advice. <smile/>

On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due <[hidden email]> wrote:

> I have been studying the documentation and the tutorial and come to the
> conclusion that patching is out, since that is essentially just the
> difference between two installers which is exactly what I want to avoid;
> Writing two installers...
>
> So, my next thought is: How about merge modules then?
>
> What I mean is, that I put all the common stuff into a merge module, it
> seems that it can contain all the logic regarding files and components
> and installing/starting services etc.
>
> Then I write the installer for each customer, which contains only the
> customer specific bits and adds the merge module containing all the
> common bit etc.
>
> So far so good. But how about the UI? Can I contain MOST of the gui in
> the merge module and only add a few customer specific dialogs (if
> necessary) in the customer installer, and if so, how do inject dialogs
> like that?
>
> Best regards,
> Thomas Due - Software Developer
>
> -----Original Message-----
> From: Thomas Due
> Sent: 22. oktober 2009 09:13
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to best install generic system with
> customerspecific add-ins
>
> I am currently finishing up on a generic system which we will sell to
> many different customer with different needs. So, as a result this
> generic system is based on extensions, or add-ins.
>
> Now I am thinking how to best write an installer for this.
> Although I could copy-n-paste the entire WiX project every time I make a
> new customer-specific extension, I think that is quite the wrong way to
> go about writing the installer for this system.
>
> So, I am thinking patches, or maybe transformations?
>
> An installer for the system itself, and then a patch with the customer
> specific bits. This way, I get to maintain a single installer with
> upgrade codes etc. and a simple patch installer for each customer
> project. On paper that should be simple enough, but how do I do that?
>
> I am currently still learning WiX, so my knowledge is, at best, shaky.
> So I need a bit of help.
>
> How do I create patches for a specific installer, and is the plan
> actually sound?
>
> Best regards,
> Thomas Due - Software Developer
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

saschabeaumont

Re: How to best install generic system with customerspecific add-ins

Reply Threaded

In reply to this post by Thomas Due

As Rob suggests, wixlibs are one way to go.

My builds aren't overly huge, so I just have a bunch of "shared" wxs
files that I use with a number of projects, with a whole bunch of
fragments in them. Fragments are awesome ;)

Common\UI.wxs
Common\CommonFeature.wxs
Common\LaunchConditions.wxi
...
Product1\Configuration.wxi
Product1\Product.wxs
Product1\MoreStuff.wxs
...
Product2\Configuration.wxi
Product2\Product.wxs
Product2\EvenMoreStuff.wxs

I pretty much just copy/paste Configuration.wxi and Product.wxs for
each product, and then add additional per-product fragments as
required, a lot of the time I'll start developing something in one
product and then later migrate it into the "Common" folder if it's
needed by another product.

If you've got a big product that takes a while to install, then
wixlibs are probably the better bet :)

Sascha

On Thu, Oct 22, 2009 at 7:27 PM, Thomas Due <[hidden email]> wrote:

> I have been studying the documentation and the tutorial and come to the
> conclusion that patching is out, since that is essentially just the
> difference between two installers which is exactly what I want to avoid;
> Writing two installers...
>
> So, my next thought is: How about merge modules then?
>
> What I mean is, that I put all the common stuff into a merge module, it
> seems that it can contain all the logic regarding files and components
> and installing/starting services etc.
>
> Then I write the installer for each customer, which contains only the
> customer specific bits and adds the merge module containing all the
> common bit etc.
>
> So far so good. But how about the UI? Can I contain MOST of the gui in
> the merge module and only add a few customer specific dialogs (if
> necessary) in the customer installer, and if so, how do inject dialogs
> like that?
>
> Best regards,
> Thomas Due - Software Developer
>
> -----Original Message-----
> From: Thomas Due
> Sent: 22. oktober 2009 09:13
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to best install generic system with
> customerspecific add-ins
>
> I am currently finishing up on a generic system which we will sell to
> many different customer with different needs. So, as a result this
> generic system is based on extensions, or add-ins.
>
> Now I am thinking how to best write an installer for this.
> Although I could copy-n-paste the entire WiX project every time I make a
> new customer-specific extension, I think that is quite the wrong way to
> go about writing the installer for this system.
>
> So, I am thinking patches, or maybe transformations?
>
> An installer for the system itself, and then a patch with the customer
> specific bits. This way, I get to maintain a single installer with
> upgrade codes etc. and a simple patch installer for each customer
> project. On paper that should be simple enough, but how do I do that?
>
> I am currently still learning WiX, so my knowledge is, at best, shaky.
> So I need a bit of help.
>
> How do I create patches for a specific installer, and is the plan
> actually sound?
>
> Best regards,
> Thomas Due - Software Developer
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Thomas Due

Re: How to best install generic system withcustomerspecific add-ins

Reply Threaded

In reply to this post by Rob Mensching-7

Fair enough, I'll try to explain the situation a little better, but Sascha's suggestion about shared fragments files makes absolute sense now that I think about it. It hadn't even crossed my mind. I would to be careful about how I shared them, so I would only have one actual copy of the fragments files, otherwise I would face hell updating all copies when there were changes to the common files.

Anyway:

I have a service with a couple of common libraries, in itself this service does nothing. It merely forms an extensible framework for customer specific functions.

Then I have the customer specific functions, these are "just" dll assemblies which are added to the service and supplies the actual functionality.

So, instead of having to copy-and-paste a generic WiX project to each customer project, I thought I would make a generic module which contains the service and common assemblies, the necessary functionality for installing and starting the service etc.
Additionally it would contain the UI sequence but allow for customer specific dialogs.

This module would then be added to a customer specific installer which contained the remaining logic, like adding the customer extension to the framework and other various customer specific actions.

This is what I want, how do I do that best?

Merge Modules?
WiX libraries?
Shared WiX fragments?

Best regards,

Thomas Due

-----Original Message-----
From: Rob Mensching [mailto:[hidden email]]
Sent: 22. oktober 2009 17:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins

If Merge Modules look like they will work, I'd use .wixlibs instead (
http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them).
The WiX toolset's reusable functionality (from the Extensions and all the
UI) use .wixlibs. The Wix.chm has a nice section on how to customize
dialogs. I'd start there. Without more details about your exact project
it's hard to provide more detailed advice. <smile/>

On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due <[hidden email]> wrote:

Blair-2

Re: How to best install generic system withcustomerspecific add-ins

Reply Threaded

The difference between wixlibs and shared wix fragments is that the wixlibs
are simply several shared compiled wix fragments joined into a single
"library" file. That would ensure you don't have multiple copies of the
sources, but would require that you compile them, either from their own
projects in your solution(s) or into some "super-library" repository you
simply grab at either buildtime or version control sync time.

Either one is usually vastly superior to merge modules. Merge modules have
several limitations that makes them more difficult to service, including
issues related to patching. Their content lives in a strange world where
they are live in your MSI but stand apart from all other content in that
MSI. They bulk up the size and slow down the performance of your MSI due to
the way they integrate in (created system folder custom actions,
difficulties in being referenced from your MSI-specific authoring, etc.).

The closest build-style to merge modules on your list would be wixlibs (you
can build and managed them the exact same way, without the merge
module-specific pain). Or, you simply link in your projects to the source
files wherever you place them for the shared fragment solution.

One other thing superior with the wixlib/shared fragments approach over the
MSM one is that any fragments you don't access in some way aren't included
in the final link, meaning they don't take up any room in your MSI. That
means you can always include all of them in all your projects, and just
reference what you need. Merge modules, once built, are an all-or-nothing
where simply including them includes everything in the MSM in your MSI,
whether you really needed it or not.

-----Original Message-----
From: Thomas Due [mailto:[hidden email]]
Sent: Thursday, October 22, 2009 11:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to best install generic system
withcustomerspecific add-ins

Fair enough, I'll try to explain the situation a little better, but Sascha's
suggestion about shared fragments files makes absolute sense now that I
think about it. It hadn't even crossed my mind. I would to be careful about
how I shared them, so I would only have one actual copy of the fragments
files, otherwise I would face hell updating all copies when there were
changes to the common files.

Anyway:

I have a service with a couple of common libraries, in itself this service
does nothing. It merely forms an extensible framework for customer specific
functions.

Then I have the customer specific functions, these are "just" dll assemblies
which are added to the service and supplies the actual functionality.

So, instead of having to copy-and-paste a generic WiX project to each
customer project, I thought I would make a generic module which contains the
service and common assemblies, the necessary functionality for installing
and starting the service etc.
Additionally it would contain the UI sequence but allow for customer
specific dialogs.

This module would then be added to a customer specific installer which
contained the remaining logic, like adding the customer extension to the
framework and other various customer specific actions.

This is what I want, how do I do that best?

Merge Modules?
WiX libraries?
Shared WiX fragments?

Best regards,

Thomas Due

-----Original Message-----
From: Rob Mensching [mailto:[hidden email]]
Sent: 22. oktober 2009 17:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to best install generic system
withcustomerspecific add-ins

If Merge Modules look like they will work, I'd use .wixlibs instead (
http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-
would-you-use-them).
The WiX toolset's reusable functionality (from the Extensions and all the
UI) use .wixlibs. The Wix.chm has a nice section on how to customize
dialogs. I'd start there. Without more details about your exact project
it's hard to provide more detailed advice. <smile/>

On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due <[hidden email]> wrote:

----------------------------------------------------------------------------
--

> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
virtually, Rob Mensching - http://RobMensching.com LLC

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Thomas Due

Re: How to best install genericsystem withcustomerspecific add-ins

Reply Threaded

Cool, that actually sounds like a clever plan.
Thanks for the input.

Best regards,
Thomas Due

-----Original Message-----
From: Blair [mailto:[hidden email]]
Sent: 23. oktober 2009 10:29
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to best install genericsystem
withcustomerspecific add-ins

The difference between wixlibs and shared wix fragments is that the
wixlibs
are simply several shared compiled wix fragments joined into a single
"library" file. That would ensure you don't have multiple copies of the
sources, but would require that you compile them, either from their own
projects in your solution(s) or into some "super-library" repository you
simply grab at either buildtime or version control sync time.

Either one is usually vastly superior to merge modules. Merge modules
have
several limitations that makes them more difficult to service, including
issues related to patching. Their content lives in a strange world where
they are live in your MSI but stand apart from all other content in that
MSI. They bulk up the size and slow down the performance of your MSI due
to
the way they integrate in (created system folder custom actions,
difficulties in being referenced from your MSI-specific authoring,
etc.).

The closest build-style to merge modules on your list would be wixlibs
(you
can build and managed them the exact same way, without the merge
module-specific pain). Or, you simply link in your projects to the
source
files wherever you place them for the shared fragment solution.

One other thing superior with the wixlib/shared fragments approach over
the
MSM one is that any fragments you don't access in some way aren't
included
in the final link, meaning they don't take up any room in your MSI. That
means you can always include all of them in all your projects, and just
reference what you need. Merge modules, once built, are an
all-or-nothing
where simply including them includes everything in the MSM in your MSI,
whether you really needed it or not.

-----Original Message-----
From: Thomas Due [mailto:[hidden email]]
Sent: Thursday, October 22, 2009 11:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to best install generic system
withcustomerspecific add-ins

Fair enough, I'll try to explain the situation a little better, but
Sascha's
suggestion about shared fragments files makes absolute sense now that I
think about it. It hadn't even crossed my mind. I would to be careful
about
how I shared them, so I would only have one actual copy of the fragments
files, otherwise I would face hell updating all copies when there were
changes to the common files.

Anyway:

I have a service with a couple of common libraries, in itself this
service
does nothing. It merely forms an extensible framework for customer
specific
functions.

Then I have the customer specific functions, these are "just" dll
assemblies
which are added to the service and supplies the actual functionality.

So, instead of having to copy-and-paste a generic WiX project to each
customer project, I thought I would make a generic module which contains
the
service and common assemblies, the necessary functionality for
installing
and starting the service etc.
Additionally it would contain the UI sequence but allow for customer
specific dialogs.

This module would then be added to a customer specific installer which
contained the remaining logic, like adding the customer extension to the
framework and other various customer specific actions.

This is what I want, how do I do that best?

Merge Modules?
WiX libraries?
Shared WiX fragments?

Best regards,

Thomas Due

-----Original Message-----
From: Rob Mensching [mailto:[hidden email]]
Sent: 22. oktober 2009 17:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to best install generic system
withcustomerspecific add-ins

If Merge Modules look like they will work, I'd use .wixlibs instead (
http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-
why-
would-you-use-them).
The WiX toolset's reusable functionality (from the Extensions and all
the
UI) use .wixlibs. The Wix.chm has a nice section on how to customize
dialogs. I'd start there. Without more details about your exact project
it's hard to provide more detailed advice. <smile/>

On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due <[hidden email]>
wrote:

> I have been studying the documentation and the tutorial and come to
the
> conclusion that patching is out, since that is essentially just the
> difference between two installers which is exactly what I want to
avoid;
> Writing two installers...
>
> So, my next thought is: How about merge modules then?
>
> What I mean is, that I put all the common stuff into a merge module,
it

> seems that it can contain all the logic regarding files and components
> and installing/starting services etc.
>
> Then I write the installer for each customer, which contains only the
> customer specific bits and adds the merge module containing all the
> common bit etc.
>
> So far so good. But how about the UI? Can I contain MOST of the gui in
> the merge module and only add a few customer specific dialogs (if
> necessary) in the customer installer, and if so, how do inject dialogs
> like that?
>
> Best regards,
> Thomas Due - Software Developer
>
> -----Original Message-----
> From: Thomas Due
> Sent: 22. oktober 2009 09:13
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to best install generic system with
> customerspecific add-ins
>
> I am currently finishing up on a generic system which we will sell to
> many different customer with different needs. So, as a result this
> generic system is based on extensions, or add-ins.
>
> Now I am thinking how to best write an installer for this.
> Although I could copy-n-paste the entire WiX project every time I make

a
> new customer-specific extension, I think that is quite the wrong way
to

> go about writing the installer for this system.
>
> So, I am thinking patches, or maybe transformations?
>
> An installer for the system itself, and then a patch with the customer
> specific bits. This way, I get to maintain a single installer with
> upgrade codes etc. and a simple patch installer for each customer
> project. On paper that should be simple enough, but how do I do that?
>
> I am currently still learning WiX, so my knowledge is, at best, shaky.
> So I need a bit of help.
>
> How do I create patches for a specific installer, and is the plan
> actually sound?
>
> Best regards,
> Thomas Due - Software Developer
>
>
>
>
>
>

------------------------------------------------------------------------
----
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
your
> developing skills, take BlackBerry mobile applications to market and
stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
virtually, Rob Mensching - http://RobMensching.com LLC

------------------------------------------------------------------------
----
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

saschabeaumont

Re: How to best install generic system withcustomerspecific add-ins

Reply Threaded

In reply to this post by Blair-2

What Blair highlights below is probably the best misunderstood feature
of wixlib/shared fragments - you can reference *.wxs and *.wixobj each
time you build, but only the fragments that are referenced are
included in the MSI output.

Meaning you can have a large number of fragments in your common/shared
directory, and your "main" project just needs to make appropriate use
of ComponentRef, ComponentGroupRef, CustomActionRef, UIRef, etc. You
can have fragments as big or as small as you like and one reference
pulls in the whole component. (nested ComponentGroupRef's come in
handy as well)

Note that if if your setup takes a long time to compile, and/or the
shared components rarely change then it is probably better to use
wixlibs - my setup compiles very quickly so I'm happy to recompile
everything each time.

Sascha

> One other thing superior with the wixlib/shared fragments approach over the
> MSM one is that any fragments you don't access in some way aren't included
> in the final link, meaning they don't take up any room in your MSI. That
> means you can always include all of them in all your projects, and just
> reference what you need. Merge modules, once built, are an all-or-nothing
> where simply including them includes everything in the MSM in your MSI,
> whether you really needed it or not.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users