[wix-users] Adding file to the install package

Edwin Castro egcastr at gmail.com
Tue Aug 7 08:34:38 PDT 2018


On Tue, Aug 7, 2018 at 7:27 AM, Elena Aralla <elena.aralla at gmail.com> wrote:

> Hi,
>
> after reading these articles, I have clearer ideas, but there are still
> some things that I don’t understand.
>
> Let's say, for example, that my program must use a specific dll.
>
> The setup installs it.
>
> Exit a new version of the dll and add it to my setup (changing the source
> in the component that already contained it)
>
> I realize that the new version of the dll breaks everything and I want to
> go back to the previous version. The setup, from what I understand, does
> not reinstall it, because it finds a more recent version; what can I do?
>


I don't personally run into this problem. Our builds always increase and we
fix problems by increasing our versions. We never, ever downgrade to fix a
problem. We change the source code and rebuild with an increased version. I
expect other people might employ that strategy so they might be able to
give you better advice.

My initial brainstorm would be to delete the current component containing
the bad dll, add a new component (different guid) for the good dll, and
ensure that RemoveExistingProducts is scheduled "early" (for example, after
InstallInitialize) so that the bad component is uninstalled before the good
component is installed. Not having done this before I don't know for
certain whether this would work. You'd have to try out this scenario. Oh, I
should mention, I'm assuming you're producing major upgrades. Personally, I
always stick to major upgrades.



> if I have a thousand files, do I have to manually change the guid of each
> component that contains it to make sure they are updated during an upgrade?
>


No, typically you would not change component guid between upgrades. The
component guid is one of the things the windows installer uses to determine
the identify of a component. If you change the guid, then you are not
upgrading a component with a newer version of a resource but rather you are
uninstalling the old component and installing a new component. This is
probably a very nuanced difference but it is a difference.

In fact, in most cases you don't even have to think about component guids
at all if you always implement major upgrades with RemoveExistingProducts
scheduled early (for example, after InstallInitialize) and always use a
file (preferably a versioned file) or a registry value as the key path to
each component. Scheduling RemoveExistingProducts early gives you the most
flexibility in changing components when you need to and using a file or a
registry value as the key path for each component allows WiX to generate
stable guids for your components. Generally speaking you wan to install a
single resource per component to allow each resource to be updated
independently from each other.

That said, there are some resources that should (or must) be installed
together. For example, if you are installing a windows service then you
must have the service definition in the same component that has the
executable for this service. Another example, many .NET applications have
an application config that is highly coupled with the application exe.
Since you'd always update the application config every time you upgrade the
application exe, then you should probably include both files in the same
component with the application exe (which is versioned) as the key path.
Per-user or per-machine config (the stuff that could be legitimately
changed by a user or a system administrator) probably shouldn't be
installed at all but rather generated at runtime by the application on
first run but if you have to install a template for such configs, then they
may or may not change independently of the application exe. The choice of
whether they should be in the same component as the application exe will
depend on those factors. When in doubt, keep them in separate components
and allow WiX to generate your guids for you whenever possible.

When I'm authoring a .wxs I always begin by authoring *only* required
attributes. I only author other attributes if I need to change defaults
because the default behavior doesn't match my needs. Following this
approach allows me to think less about how all this stuff works because the
WiX defaults generally are the right defaults for most cases.


Thank you,
> Elena.
>


More information about the wix-users mailing list