Coffeehouse Thread

42 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

ClickOnce and alternative browsers

Back to Forum: Coffeehouse
  • User profile image
    Sven Groot

    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.

  • User profile image
    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.

  • User profile image
    Sven Groot

    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.

  • User profile image
    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.

  • User profile image
    blowdart

    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.

  • User profile image
    Sven Groot

    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?

  • User profile image
    sbc

    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).

  • User profile image
    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?"

  • User profile image
    ManipUni

    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.

  • User profile image
    Sven Groot

    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.

  • User profile image
    Sampy

    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.

  • User profile image
    Minh

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

    PS, Did Wash died in Serenity?

  • User profile image
    Sven Groot

    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.

  • User profile image
    Sven Groot

    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.

  • User profile image
    Sampy

    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.

  • User profile image
    ScanIAm

    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?

  • User profile image
    geekling

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

  • User profile image
    sbc

    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?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.