> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bob Arnson > Sent: Sunday, July 23, 2006 3:54 PM > To: [EMAIL PROTECTED] > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Should WiX add support for > installingWindowsinstrumentation features? > > Phil Wilson wrote: > > There are other issues with Installer classes too. As Rob M > has pointed out, > > anything that's installed with code is outside the Windows > Installer ref > > counting scheme. If you install a shared item with MSI and > follow the usual > > component id rules it just works. Two products can share > the same resource > > (registry entry, service, file) and you can uninstall one > without impacting > > the other. When services and registry entries (snap-in > registration, COM > > registration etc) are installed with code like Installer > classes there is no > > reference counting. Products sharing these resources are > easily broken by > > uninstalling one of them. > > > > Regarding "Microsoft has adopted the Installer classes as > the standard way > > to install "things" ", it's more accurate to say that > Microsoft has adopted > > them as the standard way for *developers* to install > things. This is Visual > > Studio that started them, remember, to provide a way for > developers to get > > their "things" installed without building MSI files (mainly with > > InstallUtil). The idea that Installer classes should be > used in production > > environments can pretty much be shot down based on the ref > counting issue > > alone. The rest of it (the fragility, loading the CLR, kb > 906766, lack of > > repair) are other things that make Installer classes undesirable. > > > Do you mind if I make a macro of this message and re-post it > at regular > intervals?<g>
Reposting this message at regular intervals (either manually or automatically) does no good whatsoever. If there are problems with the Installer based classes they should be reported to Microsoft so that the problems can be fixed. If you read the documentation for the Installer classes, it never implies that they are merely developer hacks that shouldn't be used in a production environment. In fact, Visual Studio provides the InstallUtilLib custom action to call Installer classes from an MSI. The whole "anything that's installed with code is outside the Windows Installer ref counting scheme" argument is a red herring, WiX already provides ways to break reference counting (CAQuietExec). It's not using Installer classes they breaks reference counting, it's misusing them. Don't all custom actions have the potential to break reference counting? Why use the reference counting argument against one custom action but not others? Installer classes have way too much momentum and too many supporters within Microsoft to be ignored, it's time for WiX and Windows Installer to figure out how to support them. That's just my two cents (and, I don't actually use Installer classes!) John Vottero ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
