Response inline...
On Sat, Oct 3, 2009 at 3:37 PM, Blair <os...@live.com> wrote:
> ...have WiX (v3) autogenerate
> the component guids (use compone...@guid='*')
I think I will do this from now on. If I understand correctly, I can't
change this on existing components though.
I also have the default install dir (the one that the user can choose) as a
variable in my WiX code because we produce a couple "products" or custom
builds for OEMs from the same basic code. There are a few "flavors" of the
product that aren't different enough to warrent maintaining independant
installer code. It seems I made a mistake in making all of these use the
same product code, because I wanted a simple way to enforce only installing
one "flavor" at a time. I'm going to change that so they all use the same
upgrade code but I will use "*" for the product code. I think that makes
sense.
If the keypath and its directory path stay the same, wix will always produce
> the same guid for that file. If a component is removed, that is OK in major
> upgrades (as long as all the resources associated with that component go
> away with it). If a component is added, that is ALWAYS OK. If you rename a
> file, the component guid changes (effectively removing the old component
> and
> adding a new component.
>
When you write "rename a file", you mean the keypath? Because you go on to
say...
If you rename a file (or its directory) you need to change all of the other
> associated resources that are not the keypath (such as non-keypath registry
> (COM, etc.) values, etc.) so they are different. Don't move non-keypath
> resources from one component to another.
>
This is where I always run into problems. We often seem to want to add,
remove or rename files that are in the same component. It happens all the
time, and the only way I see around it is to only allow one file per
component in the first place. That makes for very verbose WiX source
files. But more to the point that is what is out there now, so I have to
deal with it.
For example, we will get an SDK from a third party. We wrap the
functionality it provides with our own DLL to integrate it with our
product. We choose to bundle the third party DLLs and our own DLL together
in the same component because it seems like the right thing to do at the
time ("associate resources with the file they belong to"). Then we get an
update to the SDK that we must integrate, now the third party has added a
DLL or renamed one of them. We can't move things to a new path without
doing major work in the rest of our application. It seems the component
rules are broken in this case and we can't do anything about it. The same
senario happens all the time just from the basic evolution of our own code.
The basic rule is
> to always associate resources with the file they "belong to" and to not
> rename files (except to move resources around).
>
I understand, but it is this basic thing that I find so difficult to do in
any non-trivial project - without psychic powers or a time machine. Things
just don't stay that much the same. What belongs together in version 1 is
not the same as what belongs together in version 2.
As to the buggy nature of the scenario you used, it is because Microsoft
> uses a relatively simple algorithm to manage components, and as Raymond
> Chen
> would tell you about supporting legacy uses, it would be very difficult for
> them to change it now.
>
If you asked me who has more experience and resources to fix this problem I
would have to say that the answer is Microsoft. Microsoft could fix it once
and for all, rather than the ALL having to find fixes over and over again
for Microsoft. How exactly is this a "legacy use" ? How long has the
problem been known? How many broken installs are out there that would "just
work" if this was fixed?
Thanks for your help!
Scott
> -----Original Message-----
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Saturday, October 03, 2009 4:32 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
>
> So it's a bug in Windows Installer - since it is doing two deletes of the
> original file, one in a moved location and one in the original location.
> It
> could cross-reference with the pending-delete list (always, or even just
> when it decides that it has to move the original out of the way).
>
> Obviously I can't wait for Microsoft to fix it. But following the component
> rules is a tremendous burden (I am dealing with around 900 files, not
> counting the merge module). I understand why they are the way they are, but
> it's still hard to manage. WiX installs are already extremely verbose and
> difficult to maintain. The component rules are so easy to break and there
> aren't good automated checks and balances. It would really like to see
> some
> tools to help in that regard. As I mentioned a tool that could check to
> see
> if rules were broken between v1.msi and v2.msi should be possible and would
> help a great deal.
>
> I'm going to see if I can educate the rest of the developers about the
> component rules. (Why does everyone hate doing installers?) - I'm just so
> scared that I'm going to screw up the rules and it will go unnoticed until
> it causes problems for a few customers. Testing every possible upgrade
> senario is something we just don't have resources for.
>
> What are the down sides to re-generating component GUIDs for every
> component
> for every build of the installer? If I will always be doing Major
> upgrades,
> will I still have problems?
>
> Does WiX/MSI have any facility for finding and terminating a process before
> continuing with the install?
>
>
> Scott
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
