Scott Hanselman

I blogged a few years back about how I was disappointed that ClickOnce didn't work in FireFox, and about a year ago Saurabh (MSFT) wrote a response.

"There have been Plugins written by the FireFox community
[e.g. http://www.softwarepunk.com/cohelper/] where they parse the application after it has been downloaded and read the deploymentProvider Url from it. They then use the undocumented Apis for invoking ClickOnce with the URL as a parameter [rundll32 dfshim.dll,ShOpenVerbApplication URL ]. I have never tried the approach above, but would believe it works.
From the ClickOnce teams perspective we would advise users against parsing the ClickOnce manifest and relying on its format for we could inadvertently break you in future manifest updates. Also since the <deploymentProvider> tag is only needed in Shell Visible installed ClickOnce applications this solution does not work for Online ClickOnce Apps.

For out next release we are looking into what we can do to provide a simple public way for the FireFox community to build plugins for ClickOnce support. Stay tuned ..."

I'm still waiting for direct XBrowser support, but I can report that FFClickOnce (James Dobson's Blog) totally works, with both online and offline apps. It makes ClickOnce work in your FireFox browser. There are a few other small add-ins that were attempts at making ClickOnce work, but James' is the most elegant and best tested, by far.

His documentation is impeccable and includes a testing section. It also scans automatically for .NET CLRs on your system and adds them to your FireFox UserAgent - a brilliant touch.

Here's what you see with Firefox 2.0.0.1:

Here's what you see in earlier versions of Firefox:

You can also turn this dialog off in the options for the Add-in and just run the ClickOnce apps directly without the interstitial.

I would encourage everyone who loves both FireFox and .NET to go get the FFClickOnce Extension now.

If you're working on a web application that has a ClickOnce component, I recommend that you include this extension as part of your strategy, and change your web page's flow to something like this:

• User clicks the "Download Client" link...
• If .NET CLR exists in the HTTP User-Agent header and it's version is greater than 2.0, issue an HTTP 302 redirect directly to your .application ClickOnce file. Done.
• If the .NET CLR doesn't exist, redirect the user to a requirements page where they can download the .NET 2.0 runtime directly and then relaunch the application. Done.
• On this page, if you detect they are running FireFox, link them to FFClickOnce as a prerequisite.

A flow like this will ensure that the user can click Download Client and it will Just Work. It works great for us.

You could also make a new publish.htm page (the static page that is generated when you publish a ClickOnce application, and write Firefox-specific JavaScript to list the installed extensions. This solution seems yucky to me, but would catch the obscure edge-case where the user has FFClickOnce install, but has modified their User-Agent string.

Thanks to James Dobson and Adam Greene for their (direct and indirect) help!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By