Can you provide more information about these files that are getting
replaced? The Windows Installer its rules for File Version checks
(documented in the MSI SDK) and they are consistent. You'd have to use a
custom action to install files (a huge no-no) to install files differently.

The whole design sounds very suspicious right now but more details may
better explain what is going on and provide suggestions.

On Mon, Jan 11, 2010 at 5:06 PM, Daniel Hughes <daniel.hug...@tait.co.nz>wrote:

> We are moving one of products from a old Install shield installer to a
> WiX installer.
>
> The old Installer installs a bunch of assemblies to the System32 folder.
> These assemblies are not produced by us but a required dependencies of
> our software. Install Shield has a replace if older type option so it
> checks the assemblies version and only installs if the existing assembly
> is older then the one being installed.
>
> When we moved to WiX there was no such option. Each assembly gets a
> component GUID and install shield just goes along and replaces any
> existing assemblies even if they are newer. This is causing problems as
> some of our customers are running software which relies on functionary
> only available in newer versions.
>
> I have heard that a way to get the correct component GUID so windows
> installer doesn't do bad things is to find official Merge Modules. These
> have proved to be hard to find and if the assembles have been copied or
> installed to Windows32 by some other method it will not work.
>
> How do I make sure I don't replace new versions of assemblies which we
> don't produce and don't control.
>
> Cheers,
> Daniel
>
> =======================================================================
> This email, including any attachments, is only for the intended
> addressee.  It is subject to copyright, is confidential and may be
> the subject of legal or other privilege, none of which is waived or
> lost by reason of this transmission.
> If the receiver is not the intended addressee, please accept our
> apologies, notify us by return, delete all copies and perform no
> other act on the email.
> Unfortunately, we cannot warrant that the email has not been
>  altered or corrupted during transmission.
> =======================================================================
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to