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>
-- sig://boB http://bobs.org ------------------------------------------------------------------------- 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
