First, you should not be packaging someone else's resources in your MSI. You should be getting a Merge Module that has all of the COM and DLL and most importantly the *correct* Component GUIDs. That's what Merge Modules were designed for. If you're not getting a Merge Module and the producer shares the resource with other people you're now very much in jeopardy of entering DLL Hell.
Second, if you're screwed then you're screwed. Personally, I always start pushing for crappy resources to get pushed out of the product. Setup failures are deadly for customers. They almost always turn into support calls (and everyone I've talked to, support calls are an undesirable expense). Of course, sometimes the developer on setup doesn't get to make that call. <smile/> If you want people to help brainstorm how to work around a particular issue then understand that most people here will suggest fixing the core issue rather than avoiding it. So be very clear that you've exhausted all options and be very specific about what you're trying to accomplish. Workaround suggestions are often very specific to the scenario so if you're not clear the suggestions you get might not work... or not work the way you want when you try to update your app some months later. <smile/> Finally, "advertising" is generally considered part of assigning/publishing in Windows Installer. The MSI SDK has stuff about it. Based on my experience, advertising shortcuts and extensions works well but COM advertising has some a rather unpleasant user experience and side effects. -----Original Message----- From: Troy Howard [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2008 02:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM registration weirdness 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. Regarding the situation that I just finished with, I would like to have a deeper understanding of the term "Advertise" that is being used in WiX/MSI contexts. What does this mean exactly, in relation to COM DLLs? Rob M mentioned that: "... those actions are only necessary if you are using the Advertised features of COM registration otherwise it's all just Registry rows." I read the blog post he linked to about why advertising is bad, but it lacks a definition of what advertising is. Does that definition exist somewhere? With context regarding COM? Thanks, Troy On Thu, Oct 2, 2008 at 1:09 AM, John Hall <[EMAIL PROTECTED]>wrote: > Neil wrote: > > I have tried a > > few times to remove the unrelated code and never successfully > > got the component to work or to leave the machine working on > > uninstall. Have you ever generated the WiX registry code for > > VB6 COM component? Has anyone? > > Neil, > > I have. I wrote a custom build task that extracts the registration > information at build time [1]. > > The registration entry point is called with some registry redirection in > place, and then I harvest the created registry entries removing the > following: > > - CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731} > > - Typelibs {EA544A21-C82D-11D1-A3E4-00A0C90AEA82} and > {000204EF-0000-0000-C000-000000000046}, plus any Interfaces that > reference these two type libraries. > > This works for me. > > regards, > John > > > [1] I know this is very much frowned upon, but I always create major > upgrades and don't create patches... YMMV > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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 ------------------------------------------------------------------------- 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
