"The Component Rules" seem to be nearly impossible to follow.   
Assuming I understand them (a significant assumption), the only way to  
follow them that I can see is to not allow users to choose an install  
folder (since the rules say that every component must only install to  
one specific path - presumably so the KeyPath can be checked) and put  
every file in its own component, which is not really required, but if  
there is ever a chance in the future of files being added or removed  
to a component bad things can happen.  So it seems to be the only  
defence given I don't have a time machine to find out how the  
component might need to change in the future. Those restrictions don't  
seem practical for any non-trivial real-world installer. I'm beginning  
to think that a Major Upgrade install and any other upgrade or  
patching is simply not going to happen.  (And I suspect that following  
the component rules strictly will make MSI installs even slower, which  
won't go over well.)

Even if I could follow the component rules to the letter for my  
version 2 installer, I obviously can't "fix" the installer that is  
already out there for version 1 to follow the component rules more  
strictly. I guess the next step is to come up with a setup.exe that  
will just do the uninstall prior to invoking the new installer.  Are  
there any other options?  I'm hoping I simply don't understand the  
component rules and they aren't as unreasonable as I have been lead to  
believe.


Thanks,

Scott



On 2009-09-19, at 11:10 PM, Blair wrote:

> If you are using the C/C++ runtime MSM modules, you must place the
> RemoveExistingProducts action either right before or right after
> InstallFinalize (if you put it right before, it must be (immediately)
> preceded by an InstallExecute or InstallExecuteAgain action). See
> http://msdn.microsoft.com/library/aa371197.aspx for the four  
> positions that
> action can be in.
>
> The last two positions described on that page are the positions that  
> ARE NOT
> "in the area" of InstallInitialize, but they require strict  
> obedience to the
> component rules. The first two positions ARE "in the area" and are not
> compatible with fusion (the technology used for both SxS and GAC). The
> runtime library MSMs use SxS, which is why they require the later  
> sequencing
> of RemoveExistingProducts.
>
> Given that you are using the runtime library MSMs, I would recommend  
> moving
> to the locations around InstallFinalize and making sure you are  
> following
> the Component Rules.
>
> -----Original Message-----
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Saturday, September 19, 2009 6:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files  
> missing?
>
> There is a single custom action to run a command line after the files
> required are installed.  This command appears to work fine in the case
> where I am not uninstalling a previous product, though it doesn't
> matter much if it doesn't run.  The common component I'm installing is
> a company-private copy of a Java 6 runtime and the custom action is
> running the command to create the "shared archive" after I have
> installed all the files.
>
> As mentioned below - I read specifically that <RemoveExistingProducts
> After="InstallValidate"> will not operate correctly for installers
> using VC 2005 runtime merge modules, which both installers do.
>
> I need to do more experiments, as I am not convinced that the
> behaviour is even consistent.
>
> Thanks,
>
> Scott
>
>
> On 2009-09-18, at 5:11 PM, Blair wrote:
>
>> Does the merge module supply/use any custom actions?
>> Would the missing files be related to anything placed in the GAC?
>> Does the merge module populate any rows in the MsiAssembly or
>> MsiAssemblyName tables?
>>
>> When they say "in the area" they are referring to the first two
>> sequencing
>> positions described on this page:
>> http://msdn.microsoft.com/en-us/library/aa371197.aspx (which is what
>> you
>> appear to be trying to achieve).
>>
>> You could try moving that action to After="InstallValidate" to see
>> if that
>> makes any difference.
>>
>> -----Original Message-----
>> From: Scott Palmer [mailto:swpal...@gmail.com]
>> Sent: Friday, September 18, 2009 1:26 PM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Major Upgrade install - why are files missing?
>>
>> I have made an installer that attempts to remove a previous version
>> of a
>> product before installing the new version.The installer runs and
>> appears to
>> remove old files and coy new ones... but it at the end of it all
>> there are
>> files missing.
>>
>> I have a merge module that installs a common component into "Program
>> Files\Company Name\commonThing" and the same merge module is used in
>> version
>> 1 and version 2 of my product.   It is some files from the common
>> component(s) that are missing after installing version 2.
>>
>> I used the following blogs as reference for my major upgrade  
>> installer
>>
>>
> http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-
>> major-upgrade.aspx
>> http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!
>> 249.entry
>>
>> In particular I choose to schedule the RemoveExistingProducts action
>> to
>> emulate a full uninstall followed by an install.
>>
>> I have a comment in my code that I've copied from somewhere on the
>> interweb
>> that says:
>>
>> <!-- <RemoveExistingProducts After='InstallValidate'/> Don't do this
>> on
>> Vista for things that use VC 2005 merge modules -->
>>     <!--
>>     When RemoveExistingProducts is sequenced in the
>> InstallInitialize area
>> you effectively get
>>     an uninstall of the old product followed by an install of the new
>> product. All other things
>>     being equal, this means that file versions and Component guids
>> are
>> irrelevant.
>>     When sequenced in the InstallFinalize area the install of the new
>> product happens over the
>>     old product, so file versioning rules apply to each file being
>> installed. Component guids
>>     also matter because RemoveExistingProducts uses ref counting to
>> decide
>> whether to remove
>>     the old files or just decrement the reference count. The
>> components in
>> the new install
>>     (files and registry items) are effectively being shared with
>> those in
>> the new product, so
>>     it's important to follow component rules.
>>     If you want an upgrade to behave as if the user uninstalled the
>> old
>> product then installed
>>     the new one, then sequence RemoveExistingProducts in the
>> InstallInitialize area.
>>     -->
>>     <RemoveExistingProducts After="InstallInitialize"/>
>>
>>
>> I realize now that I don't even now which 'side' of
>> InstallInitialize counts
>> as "in" the InstallInitialize area. Is it "before" or "after"?  (It
>> seems
>> that both would be "outside" of the actual InstallInitialize of
>> course)
>>
>> In any case I don't want to get fancy, a complete uninstall/
>> reinstall is all
>> I need, not some fancy "only change the bits that need changing"
>> thing that
>> is surely going to go wrong. I just want it to work.  It doesn't.
>> I'm lost.
>> Please help. :-)
>>
>> My merge module for the common parts of course uses the same
>> component GUIDs
>> in both products and installs all files to the same paths.
>>
>> If I launch the version 2 installer again and choose to repair the
>> existing
>> install, then it clues in to the fact that files are missing and
>> installs
>> them.
>>
>> Thanks in advance,
>>
>> Scott


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to