> Regarding SelfReg, or not.... I'm not completely sure I drink > the Kool-Aid on this one. So, I understand that SelfRegCost > violates transactability rules (spell checker says > transactability is not a word >shrug<) due to MSI and how it > handles that... But what then IS the recommended way to deal > with the scenario where you have a COM DLL that you didn't > write and can't get a different version of that does some > wacky stuff in DllRegisterServer... > > How should those DLLs be handled? If we use SelfRegCost, > everything works after a successful install, but at a > rollback, or uninstall, there's no way to undo it. What if > there were CAs for RegSvr32/RegAsm, that were built-in and > easy to use, and then you could make sure that was happening > correctly, at the right times? This is similar to the > duct-tape batch file solution (one batch for install, one for > uninstall), or bunch of QtExec actions to those programs with > appropriate cmdline params. The main thing seems to be that > they are scheduled at the right time, so that uninstall calls > regsvr32 /u. > > I understand that modifying system state outside of MSI's > system is a no-no, but if you're stuck with a DLL that > operates that way, so be it.
Troy, If I remember correctly, you also get into other problems if the DLL has dependencies on other DLLs that you're installing, particularly those put into the SXS store - they're not available until after InstallFinalize. The most obvious case here is the VC runtime. Regards, John ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
