7

I have a .NET application running on windows. I want clicking on some page element (button link flash app etc) to launch my app with some special parameters. (It should run not just in IE but on WebKit based windows browsers too) During App install we suppose that user is Admin and is running Vista or Windows 7 or Later.

So my question is - Where to get examples of such interaction (WITH source of course)?

So how to make WebKit based Browser or IE call your .Net application?

zneak
  • 134,922
  • 42
  • 253
  • 328
Rella
  • 65,003
  • 109
  • 363
  • 636

5 Answers5

11

Register a custom URL Protocol Handler. Then you can specify the url using links, etc:

<a href="myapp://doSomething/>Click to run my app!</a>

I can confirm that this works in all versions of Internet Explorer. I've also tested it in the latest versions of Firefox (3.6) and Chrome (whose version escapes me). Chrome will not allow you to enter a custom protocol into the address bar, but it will launch applications from links using custom protocols.

If you have Adobe Reader installed, the acrobat:// protocol is registered. Unfortunately, SO doesn't allow links using custom protocols, so I can't add an example here I'm afraid.

Andy E
  • 338,112
  • 86
  • 474
  • 445
  • @AndyE: BTW, ironically, the link above doesn't display in FF 3.5! It works in IE 8. – John Saunders Mar 12 '10 at 01:13
  • @John Saunders: that is weird. I remember an article detailing a (now fixed) security exploit based on how Safari (WebKit) handles custom url protocols but I can't seem to find it now. – Andy E Mar 12 '10 at 01:18
  • @John Saunders: another point to note is the `itunes://` protocol created by apple, the `irc://` protocol used by mIRC and other applications. Custom protocols have been around for years, it makes sense that browsers would support them. – Andy E Mar 12 '10 at 01:19
  • @AndyE: "support them", yes. "Support them using registered protocol handlers" may be a different thing. You may recall some major controversy about Netscape using Microsoft's dialer interface 'way back. They also weren't too keen on reusing MSHTML. This led to a few court cases... – John Saunders Mar 12 '10 at 01:45
  • @John Saunders: I don't think this is the same thing as the dialer interface situation. Information in the registry is usually publicly available to any application to read and use in any way they like, it's like saying app developers wouldn't want to use COM (which, just like custom url protocol handlers, are also registry entries pointing to an application/DLL). I decided the best thing to do would be to hunt through my registry for a custom protocol - found `acrobat://` and tested in IE, Chrome & Firefox. See my updated answer. – Andy E Mar 12 '10 at 09:25
3

You can't have a Webkit-based browser to open an application directly. Your best hope (and what Apple does to open the iTunes Store) would be to have your .NET application register for opening certain types of URLs, use a link that points to an URL of this type.

For instance, if your application can open myapp:// URLs, you could use the following HTTP header:

Location: myapp://mysettings

or a more conventional link:

<a href="myapp://mysettings">Foo</a>

And then the browser will take care to open an application that can handle the myapp:// URL scheme (in this case, your application).

zneak
  • 134,922
  • 42
  • 253
  • 328
0

Given that the application to be run, and the browser, are both running on Windows, a registered protocol handler is the best way to go, assuming all interesting browsers support it. Considering that the link above is from the MSDN documentation on Internet Explorer Development, I can imagine that some browsers might not want to support this mechanism.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • so how does Steam or iTunes load from URL's? – Alastair Pitts Mar 12 '10 at 01:00
  • @Alastair: according to http://stackoverflow.com/questions/2429770/how-to-make-webkit-or-ie-call-your-application-net-from-html-page-opened-in-br/2429792#2429792, they register a protocol handler. I'm only suggesting registering as the launch application for a file extension, which I believe would be lighter-weight. – John Saunders Mar 12 '10 at 01:04
  • But less intuitive. The user still has to run the file to launch your program. – Alastair Pitts Mar 12 '10 at 01:44
  • @Alastair: I agree. If all interesting browsers support protocol handlers defined in this manner, and if non-Windows browsers are not a consideration, then the protocol handler technique is the best, by far. – John Saunders Mar 12 '10 at 01:49
  • @John: The lack solid of cross-platform support for it is a real downer. – Alastair Pitts Mar 12 '10 at 02:14
  • @Alastair: I've done a lot of cross-platform work in my career, and I can't imagine how this could be implemented in a cross-platform manner. You'd have to implement it in stdlib or something. – John Saunders Mar 12 '10 at 02:22
  • Another unexplained downvote? It's really hard to improve an answer when nobody will tell you what the problem is! – John Saunders Dec 30 '11 at 20:24
0

I'd suggest that the only way to do this is by roundtripping to the server. The webpage triggers something on the server. The app is also connected to the server. I think it's probably unreasonable to do it any other way. If you want to get really dirty, it's possible to use Flash's LocalConnection (which uses a memory mapped file for communication) to chat to a .net app. Darron Schall has managed it (but is not sharing).

If it requires an app, why bother with a web page?

spender
  • 117,338
  • 33
  • 229
  • 351
0

You can register a protocol handler that points to your application, then have a link pointing to a URL with that protocol and whatever parameters you need.

Max Shawabkeh
  • 37,799
  • 10
  • 82
  • 91
  • It should work on any conforming web browser. I know it works at least in IE, Firefox and Chrome. – Max Shawabkeh Mar 12 '10 at 01:06
  • @Max: but that would only work on Windows, right? And, "conforming" to what? The ability to register a protocol handler is Windows-specific, isn't it? Do all browsers support arbitrary URL schemes through registered protocol handlers? – John Saunders Mar 12 '10 at 01:08
  • @John Saunders: Just as much as `mailto:` links open your email client, any other protocol should open the corresponding program under any browser. Registering protocols to certain apps requires platform-specific code, but that possibility exists on every decent OS. – zneak Mar 12 '10 at 01:11
  • @zneak: but "mailto" is a well-defined protocol scheme and has been around for a long time. That would naturally work for any browser. In particular, it would work for a browser that contained a hardcoded list of protocol schemes it handles. Such a browser would not handle a newly-registered scheme. – John Saunders Mar 12 '10 at 01:14
  • @John Saunders: To be fair, the question explicitly talks about Windows, and all popular Windows browsers follow the standard protocol-handling methods that the Windows API defines. However, a quick Google search seems to indicate that UNIX also provides some mechanism for this. – Max Shawabkeh Mar 12 '10 at 01:20
  • @John Saunders: but yet, these browsers magically know which application is the default for the `mailto:` protocol. Isn't that a proof that they're looking at system defaults? That being said, a quick Google search shows that Internet Explorer will launch the registered application for any protocol: http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx . Webkit-based browsers will do the same. That's meeting OP's requirements. – zneak Mar 12 '10 at 01:26
  • @zneak: you're not distinguishing between recognizing the protocol and knowing the default application for the protocol, and using registered protocol handlers to handle the default application. One could have a hard-coded list of protocol schemes and still call the default emailer. The question is which Windows-specific techniques the browsers have decided to leverage. I recall a court case some time ago around the time that Netscape decided against using certain published interfaces. – John Saunders Mar 12 '10 at 01:42
  • @zneak: file associations are Win32. Protocol handler registration is more likely WinInet. That may be different - a competing browser might not want to use what is essentially part of IE. That's why it requires verification and not assumption. – John Saunders Mar 12 '10 at 01:43
  • @John Saunders: and yet, IE and Webkit-based browsers are still guaranteed to work with this, which is OP's problem. – zneak Mar 12 '10 at 01:44
  • @Max: I'm just looking for confirmation that "all modern browsers" use this standard Windows mechanism. I can imagine they might think it's "too much like IE". In particular is it so well-ingrained that all new browsers will immediately support it? – John Saunders Mar 12 '10 at 01:47
  • @zneak: If someone would post a link saying that webkit, or "all modern browsers" support this, then I'd be glad to stop asking for such a link to be posted. – John Saunders Mar 12 '10 at 01:48
  • @John Saunders: "Protocol handler registration is more likely WinInet." Sorry, but protocol registration is also Win32. It's exactly at the same place in the registry file associations are. This is explained in the link I've posted. – zneak Mar 12 '10 at 01:50
  • @zneak: first of all, which link did you post? I saw Andy E's link. It showed that you are correct about where in the registry the information is kept. It did not show which API, if any, was provided for creating those registry entries. I'd be interested to know if it's a WinInet API that does so. – John Saunders Mar 12 '10 at 02:13
  • @John Saunders: I posted it in a comment on this answer. It's the seventh from the top. I think it's the same Andy posted; I actually just googled "custom protocol link internet explorer" and it came up first. – zneak Mar 12 '10 at 02:30
  • @zneak: I see it now. I found the same link. Note that Andy posted a link to a blog post, not to the MSDN documentation. Note also that this is documentation from the "Internet Explorer Development" part of MSDN, so you can see why other browsers might decide not to implement this! – John Saunders Mar 12 '10 at 02:37