ClickOnce and alternative browsers | The Coffeehouse

Sven Groot
My name has 9 letters. Coincidence? I think not...

This has been mentioned elsewhere too, but I recently encountered this myself and I don't think I saw it on here.

ClickOnce requires IE to be your default browser. It won't work otherwise.

What's happening is that the <whatever>.application file used for ClickOnce contains a relative path to the manifest for the application. Internet Explorer apparently launches the ClickOnce engine passing it the original url, so the relative path works. Both Firefox and Opera (didn't test other browsers yet) download the .application file to some temp directory, then launch clickonce. Since the manifest isn't in the temp directory, ClickOnce fails.

This wouldn't be so bad if it only affected the .application file directly. I would be perfectly happy to offer up the bootstrapper setup.exe to other browsers; if the users already have .Net 2.0 installed, this would immediately launch the application. However, this bootstrapper launches the application by opening the link to the .application file in the default browser! Which, if the default browser isn't IE, doesn't work!

So is there any workaround for this? Am I going to have to tell users of other browsers "sorry guys, you gotta open this page in IE if you want my app"?

This is a huge disappointment.

EDIT: I've uploaded my workaround.

John Galt

Yet, another example (http://channel9.msdn.com/ShowPost.aspx?PostID=136589 ... see posts about bootstrappers and MS's response) that Microsoft doesn't understand installations and what the end user expects. (See Vs.net 2005 install/uninstall experience...)

This reminds me of the MDAC Merge Module that MS was going to release back in MDAC 7... I tried it out during the beta... only to find that if MDAC 7 (or later) was already installed that it would fail and cause your installation to rollback. It took me 5 months to confince Microsoft that already having the component does not constitute an error condition because the end result is the same and thus you shouldn't throw an error.... and then they didn't bother to release the damn thing...

Whomever is leading the installation teams at MS needs to be uninstalled and someone that has a clue and understands a user's expectations and how to get there consistantly and reliably for developers needs to be installed. This person should not require a restart of Microsoft, and should provide a one step steamless process without bootstrap (i.e. learning curve and complete control over all installations at MS) and should not rely on system components (i.e. The dev teams should not be doing their own installers, there should be an install builder team that does all of the installers for every platform) Said install leader should also be in charge of the development of the tool used to build the installs. (i.e. the crap that comes with VS.net is useless crap)

Yes, I just was obtuse using a metaphore that fell apart... but since no one at MS is listening anyhow, it amused me, which is saying something more than normal on this topic....

Point being: Double click Setup.exe the user (admin or end user) should next get prompted with a licence agreement and then some install specific questions such as where to put it and what components to install (i.e. no more than 2 or 3 windows at most), and then that's it until the "finish" button is clicked. When finished is clicked, an inspection of the Add/Remove Programs list should show 1 and only 1 new item in it. If a user sees anything but the licence agreement after clicking on the setup.exe or is prompted to restart before the licence agreement is shown, then you've failed.

On the update front, it should be transparent to the user, and incremental using the same technology that Windows Update uses instead of downloading huge updates constantly.

On the development front: It should be native .NET and you should be able to inherit from the base Setup and work with it directly and program it in C# or any other .NET language.

On the build front, it should generate two files: An XML file containing the "script" that tells it the order that things are installed, and the .cs file(s) that contain code that runs as a result of steps in the script.

The "boostrapper" should install one and only one thing: The .NET framework with .NET Installer and then launch the installation. Nothing else should ever be installed before the install happens. All "System components" should be merge modules that can be externally updated but don't show up in Add/Remove programs, but are incremented and decremented so that they can be removed like DLLs.

This is simple. But like MDAC already being installed being an error condition, MS doesn't understand installations....

Same goes for click once on ALL browsers.

Sven Groot
My name has 9 letters. Coincidence? I think not...

ClickOnce certainly is a huge step in the right direction, if it hadn't been for this stupid bug. Sampy, you're one of the ClickOnce people, right? Care to offer some explanation? Don't tell me you didn't even test this scenario.

AndyC

I think this may be a security bug in Firefox/Opera.

When a ClickOnce applications lauches, it should do so from it's original location, that way the security zone information for it is correct. If it downloads and then lauches from a temporary directory then it would be, to all intents and purposes, running in the local machine zone and would recieved elevated permissions.

blowdart
Peek-a-boo

AndyC wrote:
I think this may be a security bug in Firefox/Opera.

When a ClickOnce applications lauches, it should do so from it's original location, that way the security zone information for it is correct. If it downloads and then lauches from a temporary directory then it would be, to all intents and purposes, running in the local machine zone and would recieved elevated permissions.

Blaming it on Firefox and Opera, and calling it a security bug is rather harsh, when only IE will support the in browser activation that click once needs.

Sven Groot
My name has 9 letters. Coincidence? I think not...

AndyC wrote:
I think this may be a security bug in Firefox/Opera.

When a ClickOnce applications lauches, it should do so from it's original location, that way the security zone information for it is correct. If it downloads and then lauches from a temporary directory then it would be, to all intents and purposes, running in the local machine zone and would recieved elevated permissions.

Perhaps... I read on some blog that if you copy the manifest file to the appropriate location in the download folder, it does work. In that scenario, only the .application file and the manifest are on the local computer, all the other files, including the assembly itself, are still coming from the the Internet. I'm not sure what ClickOnce uses to make its zone permissions though.

Even if that was an issue though, then why didn't they make a bootstrapper that launches IE instead of the default browser? Or just launches the ClickOnce engine directly? Like I said, if I could just serve the bootstrapper I wouldn't care so much if direct links to the .application files didn't work. But why did they design a bootstrapper with such an obvious flaw?

sbc
GW R/Me

There was one app I wanted to try that used ClickOnce, but I had that problem. As a result, I doubt I will use ClickOnce applications. Except for work/development purposes, all applications I use will not be .NET applications (and as a side effect will be faster and more portable).

AndyC

blowdart wrote:

Blaming it on Firefox and Opera, and calling it a security bug is rather harsh, when only IE will support the in browser activation that click once needs.

I didn't mean that to come across as a criticism of FF/O in quite the way I think it did. Rather that, had they allowed that scenario, it may have become a potential security issue. Surely it shouldn't take too much effort to fix Firefox such that it lauches .application files correctly? Isn't that supposed to be the open source way, fix problems in the app rather than working around them?

As to why the executable doesn't just launch IE, I guess that'd not go down to well with people using Firefox/Opera and this would be a thread about "Why does ClickOnce insist on launching IE?"

ManipUni
Proving QQ for 5 years!

Click Once is cross platform/OS, and doesn't require any special infrastructure on the server side, so some of the comments above about "Microsoft needs to learn" are inappropriate.

Microsoft has learnt a lot since the failures of things like passport and many IIS specific services. The fact it has a little bug in the Windows implementation of it isn't cause to throw your arms up and have a fit.

Sven Groot
My name has 9 letters. Coincidence? I think not...

I've been doing some research, and there is a way to get around the bootstrapper flaw. It's a horribly convoluted way, but a way nonetheless.

As I suspected, when msbuild creates the bootstrapper based on the GenerateBootstrapper task, it simply dumps the required info into the resource section of the setup.exe file. Among these is the ApplicationFile property, which will be combined with the ApplicationUrl property and then apparently just launched by ShellExecuteEx. For ClickOnce from the web, this results in a http url getting passed to ShellExecuteEx, so it launches the default browser.

Since I can't modify the bootstrapper, and don't much feel like writing my own, I thought, what else can I do? If the ApplicationUrl property is omitted, the bootstrapper will simply try to launch ApplicationFile in the folder that the bootstrapper is in. Launching ClickOnce directly is out; I can't specify the path to rundll32.exe, and even if I could, I can't specify any parameters.

So there are two possibilities: place both the .application file and the manifest in the same folder as the bootstrapper, and simply omit the ApplicationUrl property. The bootstrapper will now launch the local .application file, which can find the (also local) manifest file, so it works. The other alternative is to use a simple .cmd file that launches ClickOnce directly (rundll32.exe dfshim.dll,ShOpenVerbApplication http://www.example.com/someapp.application), and put that .cmd file as the ApplicationFile.

The downside of this is that you now need to include more than one file with the bootstrapper; so it must be zipped, extracted etc. ClickOnce just became ClickALot.

One way to get around this, which I've just tried and it does work, is to include both the setup file and the .cmd file in the resources of yet another bootstrapper (which I wrote myself). That bootstrapper will extract the real bootstrapper plus the .cmd file to the temp folder and run it.

It's convoluted, but it does seem to work, and provides a way to use the bootstrapper even if IE is not your default browser. As bad as this solution is, it's the best I can think of (short of rewriting the entire bootstrapper).

EDIT: I'll probably upload this stuff to the sandbox after I've tested it some more.

Sampy
This will be the sixth time we have destroyed it and we have become exceedingly efficient at it

I heard some people talking about this around the office (I'm friends with two of the bootstrapper guys). I'll ask around and see what they've got for you guys.

Minh
WOOH! WOOH!

Scott Hanselman blogged about his adventure w/ Firefox ClickOnce aka ClickThrice-And-Doesn't-Work.

PS, Did Wash died in Serenity?

Sven Groot
My name has 9 letters. Coincidence? I think not...

SPOILERS FOR SERENITY!

Minh wrote:
PS, Did Wash died in Serenity?

Yes, he did. That's the reason for my avatar.
(select to read)

Serenity was released in the cinemas here only last Thursday.

EDIT: Sampy, I look forward to hearing more about this.

Sven Groot
My name has 9 letters. Coincidence? I think not...

I've uploaded the workaround described above. Like I said, it's a dirty hack, but it does get the job done.

Sampy, I'm still hoping to get an official response on this.

Sampy
This will be the sixth time we have destroyed it and we have become exceedingly efficient at it

As it turns out, Firefox is not a supported platform for ClickOnce. It just doesn't work. You're right as to the reason: the file needs to be activated from the URL it's at and Firefox is downloading it to temp before running it. I'm not really sure what we could have done differently to make it work in that browser. There may be potential in writing an addon that configures Firefox to launch the manifest properly. That addon could be installed as a bootstrapper package and then Firefox users would have a seemless install just like the IE users.

The bootstrapper (created by my team, remember I'm a design time guy not runtime) tries to do the "right thing" and launch the app using your default browser. When we made that call, we thought that ClickOnce would work in alternative browsers so we made the call to respect the user's preferences.

I know this sucks and had I known, I would have pushed for an answer to FF users but that's in the past. I'll look into this addon idea and see if it has legs.

ScanIAm
On a scale of 1 to 10, people are stupid.

sbc wrote:
Except for work/development purposes, all applications I use will not be .NET applications (and as a side effect will be faster and more portable).

I heard that slashdot switched over to the 'delusional cherry' flavored Kool-aid. How does it taste?

geekling
I am an artist

We appreciate the support, Sampy. I would like to see Firefox users be able to use ClickOnce applications as easily as Internet Explorer users.

sbc
GW R/Me

ScanIAm wrote:
sbc wrote:Except for work/development purposes, all applications I use will not be .NET applications (and as a side effect will be faster and more portable).

I heard that slashdot switched over to the 'delusional cherry' flavored Kool-aid. How does it taste?

I use applications that are not dependent on anything other than what comes with the OS. I put them on a USB drive so I can use them anywhere. As soon as .NET is required, the application is not completely portable. Plus you may not be able to install .NET. I also don't use Java applications much.

Most applications you get out there (for free or not) are not written in .NET.

What is wrong with using applications that do not require a runtime?

eddwo
Wheres my head at?

"not a supported platform for ClickOnce" is not a very good answer.

Its only just out of the door, and is already declared useless for >10%of surfers? After all the work to support more standards complient output from ASP.Net the Windows Forms side of the fence is still strictly IE only?
Its not exactly making the case for "Smart Clients" being as easily deployable as Web Apps.

Couldn't the .application reference the .manifest at the actual URL rather than a relative path? An patch for dfshim.dll could be made that would pull down the .manifest directly from the url in the .application.

Or someone could submit a patch to Firefox to get it to act in a different way when faced with application/x-ms-application content, it is open source after all, it might not make it into the next release (1.5) but it should be available while ClickOnce is still a viable technology.

I may be misremebering, but I seem to think the beta1 versions didn't have both .application and .manifest, there was only a .manifest file that was fetched directly from the install link. What was the reason for the introduction of the split install information, and did no one consider the fragile nature of that division?

Shouldn't we be able to email someone a .application as an attachment and have them launch the smart client app directly?
I thought that was one of the scenarios being shown off in the early "Longhorn" Concept Videos.

In that case even if the client was Outlook Express the attachment would be extracted to TemporaryInterent files and ClickOnce would not work.

blowdart
Peek-a-boo

eddwo wrote:

Or someone could submit a patch to Firefox to get it to act in a different way when faced with application/x-ms-application content.

Why would it need a change and not a specific mime type handler for firefox which will do what's needed?

eddwo
Wheres my head at?

Well if thats all thats needed, can't we get one written, submitted and packaged with the official Firefox release without too much trouble?

imekon
Bah humbug!

Sven Groot wrote:
ClickOnce requires IE to be your default browser. It won't work otherwise.

What's happening is that the <whatever>.application file used for ClickOnce contains a relative path to the manifest for the application. Internet Explorer apparently launches the ClickOnce engine passing it the original url, so the relative path works. Both Firefox and Opera (didn't test other browsers yet) download the .application file to some temp directory, then launch clickonce. Since the manifest isn't in the temp directory, ClickOnce fails.

This wouldn't be so bad if it only affected the .application file directly. I would be perfectly happy to offer up the bootstrapper setup.exe to other browsers; if the users already have .Net 2.0 installed, this would immediately launch the application. However, this bootstrapper launches the application by opening the link to the .application file in the default browser! Which, if the default browser isn't IE, doesn't work!

So is there any workaround for this? Am I going to have to tell users of other browsers "sorry guys, you gotta open this page in IE if you want my app"?

This is a huge disappointment.

EDIT: I've uploaded my workaround.

I think a more interesting question ought to be - should a browser launch an application? And further more, should a browser launch an installation?

Given security issues with such a scenario, I'd say no. I much prefer the model where whatever you click on you get a choice - download it or run it with xxx. Trouble is, a lot of things simply start running - for example Apple's Quicktime plugin takes over playing MP3's etc.

I can understand your disappointment but to me, "clickonce" sounds flawed. It may make the end user's life easier but does it also makes it too easy to install malware?

Isn't this kind of thing precisely the reason Microsoft has such a poor reputation for security?

Tensor
Im in yr house upgrading yr family

imekon wrote:

I can understand your disappointment but to me, "clickonce" sounds flawed. It may make the end user's life easier but does it also makes it too easy to install malware?

Isn't this kind of thing precisely the reason Microsoft has such a poor reputation for security?

So, are you asking these questions because you are being obtuse? Or have you just not tried it? Or do you just have no idea what Code Access Security is for?

If you can force yourself, fire up IE and try and install one of the apps via clickonce that hans posted here and you will notice that, it doesnt just install - you get security warnings before downloading the installer, and before running the installer as well (as Hans does not have a Certificate).

Click once is not a way to install malware any more than posting a link to any other executable is.

imekon
Bah humbug!

Tensor wrote:
imekon wrote:
I can understand your disappointment but to me, "clickonce" sounds flawed. It may make the end user's life easier but does it also makes it too easy to install malware?

Isn't this kind of thing precisely the reason Microsoft has such a poor reputation for security?

So, are you asking these questions because you are being obtuse? Or have you just not tried it? Or do you just have no idea what Code Access Security is for?

If you can force yourself, fire up IE and try and install one of the apps via clickonce that hans posted here and you will notice that, it doesnt just install - you get security warnings before downloading the installer, and before running the installer as well (as Hans does not have a Certificate).

Click once is not a way to install malware any more than posting a link to any other executable is.

I have no idea what Code Access Security is but I can guess from the name. How does Code Access Security differ from Access Control Lists? Not that I use ACL's. Is this yet another solution from Microsoft to security? Like the running saga we have with OLE -> ActiveX -> COM -> .NET -> whatever next?

I prefer to avoid running IE.

Instead I'll ask a couple of simple questions - can these security warnings be turned off, and are they on by default?

AndyC

imekon wrote:

I have no idea what Code Access Security is but I can guess from the name. How does Code Access Security differ from Access Control Lists? Not that I use ACL's. Is this yet another solution from Microsoft to security? Like the running saga we have with OLE -> ActiveX -> COM -> .NET -> whatever next?

I prefer to avoid running IE.

Instead I'll ask a couple of simple questions - can these security warnings be turned off, and are they on by default?

Code Access Security is nothing like ACLs. It prevents code from accessing things which it is not authorised to do. It is enforced by the .NET runtime and cannot be circumvented.

As for the security warnings, yes they are on by default, no they cannot be turned off.