I'd like to add that SelfReg was a 1980s and early 1990s concept. By the end of the 1990s it was recognized as being a prime contributor to the "DLL Hell" problem that as killing redistributables (anyone remember how messed up the VB runtime could get?).
Anyway, the Windows Installer documentation provides a number of reasons why you should not use SelfReg here: http://msdn.microsoft.com/en-us/library/aa371608%28VS.85%29.aspx. It is rare for MSDN documentation to come out and say "don't use this". We learned that SelfReg was a "bad thing" (most of us call it "evil" <smile/>) a long time ago. You are welcome to ignore the advice (it is free after all) but I would still (and always) encourage you to not use SelfReg. <smile/> On Mon, Nov 2, 2009 at 10:18 AM, Neil Sleightholm <n...@x2systems.com>wrote: > I know it sounds a pain but it is really worthwhile adopting. What > regserver does is not standard it is developer dependant and you can do > anything in that code. > > You say it would need rework when the interface changes, that is correct > but that shouldn't happen that often and should be well defined. If you > are coding in C++ then you will have to write the self reg code so will > know all the details. It sounds to me like you are using VB which is > hiding all the complexity (and in my experience making it worse). > > 1. I am not sure it is "supported", it is commonly done. > 2. I bet it doesn't just work, it works on their machines :-) Once it > gets out in the wild I have seem all sorts of issues with self reg. > 3. I am surprised but I guess you might only deploy to well known clean > environments. > 4. Personally I would argue that self reg fits that description. > > You final point about sharing is the killer for me, if you do it with > reference counting it will break, doing it with WiX registry entries > won't. Have you tried opening the InstallShield MSI with Orca to see how > they implement the self reg, it may be that it actually implements the > registry keys. > > There is no way to setup a custom action to work like this without > implementing your own reference counting. > > Obviously these are my opinions and you are welcome to ignore them! > > Neil > > -----Original Message----- > From: Daniel Hughes [mailto:daniel.hug...@tait.co.nz] > Sent: 01 November 2009 22:44 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Heat and .exe COM objects > > This is not a one off as it will need to be changed if the interface > changes. > > When I described the process to be team they all said there is no way > they are doing that, and that I should just use /regserver and > /unregserver custom actions, > > 1. They could not understand why a supported feature should not be used. > 2. They can not accept that something that just works in install shield > should not be used. > 3. They point out we have not had any problem from a install shield > installers caused by self reg. > 4. Quote "The mechanism that you are proposing as a replacement for COM > self registration sounds at first hearing about it to be labour > intensive, fiddly and brittle." > > The ActiveX exe in question are shared between multiple project and so > must only be unregistered when the last one is removed. My workmates > tell me that Install Shield keeps a count and only runs /unregserver > when the last component is removed. They want me to replicate this > behavior using WiX. > > How do I set up a custom action to unregister the ActiveX exes only when > > all programs using them are uninstalled? > > > Neil Sleightholm wrote: > > I would disagree, do it by hand, I would want to know what was being > > registered. I would be fairly sure that many of these registry entries > > > are not required. Are these exes vb by any chance, vb has a habit of > > adding extra registration - it registers the vb runtime everytime. > > Also, this is a one off and not really something that needs automating > > > as part of a build process. > > > > Neil > > > > Neil Sleightholm > > n...@x2systems.com > > > > On 29 Oct 2009, at 23:20, "Daniel Hughes" <daniel.hug...@tait.co.nz> > > wrote: > > > > > >> By the way for anyone thinking I should generate the WiX xml by hand, > >> the WiX output from the suggested method (RegSpy2 + Tallow + RegCop) > >> produces 700 lines of xml. If you have several of these ActiveX exes > > >> to > >> register like I do then doing this by hands would involve writing > >> several thousand lines of XML....... no thanks. > >> > >> Pally Sandher wrote: > >> > >>> Heat can't extract the COM information from your executable but > never > >>> fear, all is not lost quite yet. > >>> I've used a tool called RegSpy2 to harvest the /regserver > information > >>> from an out-of-process COM server executable in the past. It's > >>> available > >>> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to > > >>> the > >>> section labelled "Capture Self-Registration Information") > >>> It will output a .reg file which you'll need either manually convert > >>> into WiX code or if you want to save yourself some time you can use > >>> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow > >>> generates > >>> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't > >>> support parsing .reg files into WiX code like tallow did/does so you > >>> will need to download WiX v2.0 if you don't feel like manually > >>> writing > >>> all the RegistryKey & RegistryValue entries yourself (you don't > >>> need to > >>> install WiX v2.0 to use tallow, just download the binaries). > >>> > >>> If you have the actual object which is wrapped in the executable you > >>> could try running heat.exe on that & see if it generates the > required > >>> registration information which would save the hassle of the above > >>> process. > >>> > >>> Blair the source code for RegSpy2 is available on the above link. > >>> That > >>> may help you modify heat.exe (or write an new tool separate from > >>> heat.exe if that's what's easier). This comes up every couple of > >>> months > >>> so there's definitely people who have a use for it (I'd certainly be > >>> happier auto-generating WiX v3.0/v3.5 code than passing stuff > >>> through 3 > >>> different tools) & it might even discourage people from trying to > >>> take > >>> the easy way out and do this type of thing using Custom Actions. > >>> > >>> > >>> Palbinder Sandher > >>> Software Deployment & IT Administrator > >>> T: +44 (0) 141 945 8500 > >>> F: +44 (0) 141 945 8501 > >>> > >>> http://www.iesve.com > >>> **Design, Simulate + Innovate with the <Virtual Environment>** > >>> Integrated Environmental Solutions Limited. Registered in Scotland > >>> No. > >>> SC151456 > >>> Registered Office - Helix Building, West Of Scotland Science Park, > >>> Glasgow G20 0SP > >>> Email Disclaimer > >>> > >>> > >>> -----Original Message----- > >>> From: Blair [mailto:os...@live.com] > >>> Sent: 29 October 2009 04:42 > >>> To: 'General discussion for Windows Installer XML toolset.' > >>> Subject: Re: [WiX-users] Heat and .exe COM objects > >>> > >>> Short answer: manually. > >>> > >>> Long answer and call to action (if there is enough interest): > >>> > >>> Unlike the import methods that RegSvr32.exe calls in DLLs, the > >>> /regserver and /unregserver command line arguments are a convention > > >>> that > >>> while common is not universal. In addition, it is dangerous to run > an > >>> unknown executable since you never know if it even checks command- > >>> lines > >>> or not (that danger of running foreign code also exists with DLLs, > >>> but > >>> the likelihood of trouble is reduced since there isn't a lot you > >>> can do > >>> in DllMain and it is unlikely that DllRegisterServer will be > >>> something > >>> else). > >>> > >>> It would be possible to extend heat to call the /regserver > >>> commandline > >>> although that would require some testing and not-so-conventional > >>> process > >>> bootstrapping, but the largest difficulty is in how to communicate > to > >>> the tool which EXEs it should probe this way in a scalable fashion. > >>> > >>> If list members wish to propose ways to identify EXE files that > >>> should > >>> be harvested for COM, I am open to compiling them and distilling > some > >>> proposals back to the group for further refinement. Send them to > >>> os...@live.com with a subject of "COM .exe harvesting". > >>> > >>> -----Original Message----- > >>> From: JK E-Lists [mailto:jkli...@ifm-services.com] > >>> Sent: Wednesday, October 28, 2009 11:07 AM > >>> To: wix-users@lists.sourceforge.net > >>> Subject: [WiX-users] Heat and .exe COM objects > >>> > >>> I have an old out-of-process COM object that is wrapped in an EXE. > It > >>> uses the /regserver and /unregserver command line parameters to > >>> register > >>> and unregister the COM object. > >>> > >>> Heat appears to treat this as an ordinary executable, ignoring the > >>> fact > >>> that it's a COM object. > >>> > >>> Can Heat extract the COM information, or do I just need to do it > >>> manually? > >>> > >>> Thanks a lot! > >>> > >>> jk > >>> > >>> --- > >>> > --------------------------------------------------------------------- > >>> ---- > >>> -- > >>> Come build with us! The BlackBerry(R) 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/devconference > >>> _______________________________________________ > >>> WiX-users mailing list > >>> WiX-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/wix-users > >>> > >>> > >>> --- > >>> > --------------------------------------------------------------------- > >>> ------ > >>> Come build with us! The BlackBerry(R) 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/devconference > >>> _______________________________________________ > >>> WiX-users mailing list > >>> WiX-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/wix-users > >>> > >>> > >>> > >>> --- > >>> --- > >>> --- > >>> > --------------------------------------------------------------------- > >>> Come build with us! The BlackBerry(R) 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/devconference > >>> _______________________________________________ > >>> WiX-users mailing list > >>> WiX-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/wix-users > >>> > >>> > >>> > >> === > >> ==================================================================== > >> This email, including any attachments, is only for the intended > >> addressee. It is subject to copyright, is confidential and may be > >> the subject of legal or other privilege, none of which is waived or > >> lost by reason of this transmission. > >> If the receiver is not the intended addressee, please accept our > >> apologies, notify us by return, delete all copies and perform no > >> other act on the email. > >> Unfortunately, we cannot warrant that the email has not been > >> altered or corrupted during transmission. > >> === > >> ==================================================================== > >> > >> > >> --- > >> --- > >> --- > >> --------------------------------------------------------------------- > >> Come build with us! The BlackBerry(R) 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/devconference > >> _______________________________________________ > >> WiX-users mailing list > >> WiX-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wix-users > >> > > > > > ------------------------------------------------------------------------ > ------ > > Come build with us! The BlackBerry(R) 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/devconference > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > ======================================================================= > This email, including any attachments, is only for the intended > addressee. It is subject to copyright, is confidential and may be > the subject of legal or other privilege, none of which is waived or > lost by reason of this transmission. > If the receiver is not the intended addressee, please accept our > apologies, notify us by return, delete all copies and perform no > other act on the email. > Unfortunately, we cannot warrant that the email has not been > altered or corrupted during transmission. > ======================================================================= > > > ------------------------------------------------------------------------ > ------ > Come build with us! The BlackBerry(R) 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/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) 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/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) 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/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
