For the reused component, that should be defined in a merge module that gets merged into each download. The component reference counting done by the Windows Installer should then only remove it when the reference count is zero.
I don't have any ideas about the activation issue other than to suggest that in the case of no files present, the application is in trial mode (that way a repair won't be overwriting anything). Then, when activated, the software write somewhere that is not part of a component so that it doesn't get removed or overwritten by other components. Brant Gurganus http://gurganus.name/brant On Mon, Sep 21, 2009 at 5:53 AM, mirram...@googlemail.com <mirram...@googlemail.com> wrote: > Hi experts, > > I am relatively new to WiX have created some msi packets which work > pretty good, and now I am seeking some time-saving leads/doc > links/hints, how I can create what I consider a fairly complex > installation scenario. > > Here are the basic infos you need: > > a software is to be installed, which consists of two components: a > viewer/shell component (basically a bunch of .exe programs in c:\program > files) and lots of graphics data (a couple of hundreds of pictures, lets > call it a "pack".). > > Now for the challenges: > > 1,) The viewer component has an internet based copy protection. The > mechanism changes some of the installed files in c:\program files if a > user activates his software. The files need to be installed with the > initial install, (to put the software in a time limited demo mode), but > once altered by the activation, they may not be overwritten by a > re-installation/repair. > > 2.) The software is sold via Internet, and is divided in > packages/modules. There is no specific order a customer must stick to > when purchasing or installing. For handling reasons (the webshop cannot > handle more than one single file) every module must use just one single > msi file, and therefore every msi contains two components: the > shell/viewer component (which is always the same), and the package data. > The shell component shall be installed along with the first package > installed, and shall be removed along with the last package uninstalled. > > What I dod so far: I created two msi installers, both contain the same > component structure for the shell/viewer (same GUID), and another > component for the actual data. Installation of both packages in either > order works. > > Problems: > - no matter which package I deinstall first, the shell component does > alsways get uninstalled with it. the shell component should remain > intact until the last package gest uninstalled. > - when installing the first package, activating it, and after a while > install the second package (a customer wants "more" after a while and > purchases a second package) the installation of the second package > overwrites the shell component, and thus wrecks the internet activation > files. > - The system will grow, so the exact number of packs available in the > future cannot yet be predicted. > > I haven't looked into the details too deep yet, I guess I could fairly > easily find a condition to inhibit the installation of the shell > component if it is already installed (check for existence of a > file/directory/reg key), but how can I inhibit the deinstallation until > the shell component is not needed any more? > > In case this is not possible, I have thought about an alternative: can I > create a msi that does, during installation, spit out two software > produkts (which do appear individually in Control-Panel - Software): > > MyCompany: Shell > MyCompany: Pack 1 > MyCompany: Pack 2 > > I guess that most users would intuitively not uninstall the Shell > component unless they intend to delete the whole system and uninstall > the Packs as well (I don't care about the order of uninstallations), and > once someone uninstalled the shell it is acceptable that he needs to go > through the licensing/activating procedure again. Probably there is a > way to "link" packages togehter in a chain, so that in case someone > uninstalls thes shell, the module packs are uninstalled as well? > > Thanks for hints/ideas ... > > Armin. > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
