WIX Installer alternative

[John Tan]

Hi,

 

I know this has been discussed many times and Richard has always stressed on using WiX instead of using other installer and avoid using regsvr32 to register plugin.

 

I have tried studying WiX and created an installer but it is really creating a mess. The plugin is never registered when I deployed to a group of testers to test and the learning curve of picking up WiX is so steep. Sufficient to say, I'm do not have enough time to really study through. On the other hand, I consider myself quite proficient in in NSIS and so far, I've created quite a stable installer that seems to work. However, I'm concern with the registry entries that will still be around after the plugin is unregistered using the "regsvr32 /u" command. I suspect this could be the reason why sometimes the plugin is not properly registered in FireFox.

 

As I browse through the FBControl.rgs script, I do see lots of "NoRemove" tag. So, I wonder, by removing these tags, will it do a more proper cleanup during the plugin unregistration?

 

Thanks...

[John Tan]

OK, a mistake here....

 

I should ask, should I remove away the ForceRemove tag so that during the unregistration, it will be deleted. The NoRemove tag are on the higher branch which should be permanently there.

[Richard Bateman]

ForceRemove I believe tells it to force removal of that tag even if something has been added that isn't in the .rgs file. AFAIK there are no keys that are added that aren't removed.  The reason for using a msi (whether wix or not) is to ensure that that is the case in a journaled manner, instead of in a "well, we're pretty sure we did this before, so do the opposite of this now to uninstall" manner.

As a sidenote, one solution that you could consider is embedding a really simple .msi file inside your nsis .exe, thus letting you use the front-end tools of nsis but keeping the transactional nature of the .msi.

- Richard a.k.a. taxilian

Jun 18, 2013, в 04:04, John Tan <tjk...@gmail.com> написал(а):

-- 
 
--- 
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Tan]

Thanks Richard,

 

One thing, which I have not been able to figure out is, as you mentioned, all registry entries will be journaled but which part of the WXS code exactly is that one doing the plugin registration? As far as I can see, there aren't any part of the WXS script related to that. Neither do I see the regsvr32 is called in the WXS (Of course, that's the whole point!) nor do I see any similar registry stuff I see in the RGS.

 

Which is why, when I compiled an MSI file from the generated WXS and tried on a fresh system, it did not work.

 

[John Tan]

Another reason why I prefered NSIS was that in the installer, I have a routine which will detect any browsers currently holding on the the plugin and will stop the process if it's still loaded. It was easy to implement in NSIS but while I'm sure it's definitely doable in MSI, it's going to be too far fetch for me for now.

 

[Richard Bateman]

The reason you don't see it is because that information is compiled by
heat.exe into a np<your plugin>.wxs file.  If you look in that file and
discover no COM registration information then you're most likely missing
dependencies at build time (DLLs that your plugin needs).

One reason for using a combined msi and exe installer would be so you can
use the UI of the exe, which is usually easier, but still the MSI
transactional install.

Richard

 

--

[John Tan]

Thanks Richard....

 

OK, a quick check on heat.exe shows that when used on a COM DLL, it will generate the necessary registry item in the wxs during compilation.