Our history started with VS2003 VDPROJ MSM's consumed by InstallShield 9. This has evolved several times so that it's now WiX MSM consumed by InstallShield 2009. I'm now exploring WiX MSM consumed by WiX and InstallShield 2009 with the possibility of WiX wixlibs consumed by WiX in the future.
I try to design solutions that keep my options flexible but with a massive software product line that is active on dozens of branches and used by dozens of products it's hard to find the time. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me ----- Original Message ---- From: Rob Mensching <r...@robmensching.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Sun, July 18, 2010 10:03:00 AM Subject: Re: [WiX-users] Merging Modules and Module Dependencies I believe this is an open feature request. Implementing the feature requires opening the Merge Modules to find matching signatures. The WiX toolset doesn't persist data like that from build to build so it could a pretty bad performance hit until a solution for caching ModuleSignatures was developed. So, thus far we've fallen back on the fact that the ICE will catch the missing dependencies. Not the ideal solution but since Merge Modules continue to fall out of favor with redist producers and .wixlibs provide a better sharing mechanism in the WiX toolset, this has always been low priority. -- virtually, Rob Mensching - http://RobMensching.com LLC On Sun, Jul 18, 2010 at 7:12 AM, Christopher Painter < chr...@deploymentengineering.com> wrote: > Considering A.MSM with ModuleDependency of B.MSM, when I merge A.MSM into > P.MSI > I notice that WiX does not merge B.MSM into the MSI. This results in the > valiation warning ( really an error ) > > ICE25 WARNING Possible dependency failure as we do not find > bmm.4cca5793_5d4d_4a83_8652_d89a0c287...@1033 v1.0.0.0 in ModuleSignature > table > > I've used InstallShield in this scenario for a number of years and it > automatically merges in the dependencies for you. Unfortunatly it's always > done > it wrong in that only 1st order dependencies get their Merge Redirect > Folder > associated to INSTALLDIR and all n-th order dependencies are left > unassociated and install to C:\ ( or D:\.... ). I've always had to hack > around this with some post build steps to clean up the directory table. > > I'm wondering what the thoughts were on the WiX side to see why decisions > were > made the way they were. Based on my experience with InstallShield I always > assumed that the ModuleDependency table was instructive to the build/merge > process and not merely informational. > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
