Deployment of NPAPI plugin with minimal user steps

Question

Situation: I've already written an ActiveX control for my IE users which works perfectly. I build the .ocx, CAB it up, sign it, and put it on the site with an EMBED tag. Users load the page, the yellow bar shows up asking if they want to install it: all they have to do is click it, and we're off.

Now I need to build support for FF, Chrome, and Safari (on Mac). From my research, NPAPI is the way to do this, and Firebreath is supposed to make it easier. But from what I have read, deployment is not so easy. Windows users would have to run "regsvr32" on a DLL (which none of my web users would actually do). I have no idea what would happen on a Mac. I believe the user has to copy it to a directory like /Library/Internet\ Plugins/, which is also a non-starter for deployment. Firefox users would download/run an .xpi. Chrome is supposed to run a .crx.

Does anyone out there have experience with this? How do you do a easy-for-users-to-run deployment of an NPAPI plugin for the other big 3 browsers?

Television

Answer 1

This is a question that is raised a lot by FireBreath users, so it's probably about time I responded in more detail on a forum that is easier to find than the project google group.

First of all, to clear up the regsvr32 thing, FireBreath does indeed support "self registering" for all browsers; that means when you call regsvr32 it installs registry keys not just for IE but also for NPAPI browsers using the methods linked to by DReJ (+1 for that info, btw, thanks. Many don't know where to find it).

However, self-registering DLLs is highly discouraged in the installer world and by Microsoft. There are a lot of reasons for this. You've done a pretty good job of summarizing the other install options in your post; You can use a .cab on IE and a .XPI on firefox, but of course those don't help you on other browsers.

The method recommended by the FireBreath team (which I lead) is to use an MSI installer for all browsers. Personally, I dislike having things work differently on different browsers for an install, so I use javascript to detect the presence (or absence) of the plugin and then prompt the user to download and run the MSI installer.

FireBreath has "built-in" support for building MSI installers with WiX. If you install WiX 3.0 or later on your machine and re-run the prep script it will create a _WiXInstaller project that will build a basic MSI to install your plugin for all browsers as part of the Visual Studio build process. You can modify the .wxs template that will be left in your home directory to customize it.

More info can be found on the FireBreath wiki: http://www.firebreath.org/display/documentation/WiX+Installer+Help http://www.firebreath.org/display/[email protected]/Potential+Installer+Improvements

If you are really in love with using your .cab installer for IE (I've had problems with them, but some seem to have good luck with them) you can distribute the MSI file inside your CAB and have it run when the CAB is installed. The advantage to this is that when you install the MSI it installs everything for IE, Firefox, Safari, Chrome, and Opera (as well as other browsers which are compatible with the same plugin technologies that those browsers use).

As a quick note, the reason that an MSI is the ideal solution for installing plugins (as opposed to using something that calls DllRegisterServer like regsvr32) is that the MSI is transaction based, so when you uninstall it will always reverse what was put in; that means that you don't have to worry about supporting uninstalling 10 different old installer versions that put things in different places, etc, because the MSI system takes care of uninstalling everything cleanly when you upgrade.

Hope that helps!

Malady

I want to optimize for user ease-of-use, not developer. Running an .msi or .exe "feels" different to the average user than simply clicking a yellow bar to run a control. Are there any links or resources for packaging the plugin into XPIs (for Firefox), CRXs (for Chrome), and what do I do for Safari on Mac? – Television

The most complete docs I'm aware of other than what I just wrote is this wiki page we put up today: firebreath.org/display/documentation/… – Malady

Incidently, it looks like on Chrome and Firefox you can install a plugin as an extension. I still recommend against this -- I think you'll eventually come to the same conclusion that I have, and just use an MSI. Until then, however, you can do what you want to on at least IE, Firefox, and Chrome. You'll just have to dig to find the specifics. – Malady

Upvoted, I like the "make it the same" thinking, and I still think downloading an running an EXE (or MSI) is a more robust method of deployment than anything else. Even with all the warnings you get, users just ignore those anyway. – Compelling

Answer 2

For NPAPI plugin you shouldn't run "regsvr32", in Windows you need to write some stuff to the register and on Mac or Linux you need to copy the plugin to specified locations (see "Installing Plug-ins"). I think the easiest way to deploy NPAPI plugin on Windows is to create windows installer that will install both activeX and NPAPI versions of the plugin (for example, you can look how deployment is done for commercial plugins like Unity3D, Roozz or Silverlight). The same is for Mac - just create installer.

Combined

Answer 3

I'm not aware of any way to install a plugin from within Safari.

Also, keep in mind that while you may think of the extension-style deployment as easier for users, it's not all that uncommon for Mac users to use more than one browser. If you make them re-install your plugin in each browser they will be confused (since that's not how browser plugins are generally deployed on the Mac) and annoyed. An installer or a manual drag-and-drop installation are the standard ways of deploying plugins on the Mac.

Sedan