CommandProxy : .NET / AIR Integration Proof of Concept
mikechambers January 17th, 2008
Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0.
However, this does not mean that you cannot build an AIR application that has closer / tighter integration with the underlying operating system. This lower level of integration is possible, but it requires some work on your part. I have put together a proof of concept project, which shows how to integrate Adobe AIR applications with c# / .NET code on any operating system that Adobe AIR currently runs on (Mac and Windows). The project is called CommandProxy. It provides a communication proxy between an AIR application and the underlying operating system and could theoretically work with other web based desktop runtimes (such as Mozilla Prism).
Update : I have posted some additional thoughts on this proof of concept here.
Note, this project is in no way supported by Adobe. This is a proof of concept project that I put together to help developers understand one possible way to extend AIR functionality beyond that that is provided by the runtime.
The general concept behind the project is similar to the now defunct Artemis project (which is Java based). The AIR application communicates with the CommandProxy process to communicate and integrate with the underlying operating system. Currently the command proxy supports launching processes (and getting the output from the processes) as well as taking a screenshot of the user’s current screen. However, the framework is built in such a manner that it is possible to add new functionality to the proxy.
Here is an overview of the life-cycle of an AIR application using the command proxy.
- Command Proxy process is launched by the user. The shortcut for the process passes in the path to the AIR application to launch (or this can be hard coded into the proxy)
- The Command Proxy process then launches the AIR application, passing in a communication key, as well as the socket port that the AIR application should use to communicate with the proxy.
- The AIR app may then at some point communicate with the proxy to execute a command. For example, it may tell the proxy to launch a specific process.
- The proxy executes the specified command.
- If appropriate, the proxy then returns any command output back to the AIR application.
- The command / response cycle can occur multiple times during the application life-cycle
- When the AIR application process is terminated (i.e. the user closes the application), then the proxy process automatically exits.
Currently, the project is meant as a proof of concept, and not as a general use framework. This mainly means that there is not a lot of documentation (although the code is fully commented) and if you want to use it, you are going to have to compile the proxy yourself. If there is interest, then I am willing to expand the project to other contributors.
If you wanted to use something like this in a production level application, then you would need to:
- Compile the CommandProxy
- Compile the AIR application
- Create the AIR file to install the AIR application
- Create a custom installer that first installs the AIR application, and then installs the short cut to the command proxy
Instead of launching the AIR application directly, the user would launch the command proxy process, which would then launch the AIR application.
The project is hosted on Google code, and includes the following:
- Full C# / .NET code, compilable under Visual Studio and Mono. (Screenshots do not work under Mono)
- ActionScript 3 library for communicating with the proxy.
- Some very basic documentation
If you have questions, then post them in the comments and I will try and address them (and maybe create an FAQ on the project page). If there is interest, then I could also create a mail list on Google groups to discuss the project. If you find bugs with the code, then post them on the project’s issues page.
I am also hoping to post some examples of AIR apps that use the proxy. Lee Brimelow built a simple example of an AIR application that takes a screenshot, and then opens it in Photoshop for editing. You can see a demo of that example toward the end of the video posted here (it is about half way through the video).
Update : The code is released under an MIT License.
You can find more information on the CommandProxy project page.
Update : I have posted some additional thoughts on the code here.
[...] CommandProxy is a proof of concept by Mike Chambers (Adobe AIR team) that offers a solution to a feature that Ben and I have wanted in AIR…. the ability to talk to native code: Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0. [...]
Once again you deliver a simple, elegant, and completely wonderful example of you guys out in front of the curve.
Propellerheads from competing products have been trying to poke holes in AIR from day two, so I wonder how many of them it’ll take to spin this into some kind of nefarious security flaw or some other such schlock. I bet once they’re over being astounded and the beautiful simplicity of the proof-of-concept here, they’ll progress through their familiar territory of enraged jealously, and onto attack mode.
Now if I could actually program, I’d be even happier…
This is by far the most basic, but elegant solution I have seen to this external application issue. I lost hope when Artimis was halted, but can now see the light once again.
Also, thanks for the highly commented code, that will surely come in handy.
Thanks again,
Matt
Finally ! It took time to come to the public. That’s a really great proof of concept, I’ve tried this and it just adds a whole new level to AIR applications.
Thanks again !
Nice stuff.
@thinman: Propellerheads out there will have a deja-vu as they did with Flash Player in the first time. Now it comes to a complete development environment, they cant poke it anymore and try to poke the next one AIR. But not for long, soon they wont have anything to poke, the’ll wonder how the heck they missed the whole party poking.
Ok im back to coding :)
Adrian.
[...] UI, but recently (few months now) that project has been abandoned. It seems this new project, CommandProxy is a start in the right direction and it will be interesting to follow [...]
Very nice example! However you`ll loose the nice packaging/install/update stuff that`s build into AIR or?
When I read your post i virtualy see the Adobe AIR 1.0 underlined so there is hoping for 1.5 :-)
>Very nice example! However you`ll loose the nice packaging/install/update stuff that`s build into AIR or?
Well, you really need to do a custom installer for this (that you or someone creates for you), so you do loose some of the AIR install advantages.
However, that customer installer could also install the AIR runtime, so that would make the install pretty seamless (as download, not from browser).
As far as application update, you could still take advantage of the AIR application update functionality. It would work as expected.
mike chambers
mesh@adobe.com
Hey Mike, nice work. I know we (EffectiveUI) open sourced Artemis, but noone has been doing anything active w/ it for months.
One feature I’d like to see is some form of optional integration of Java jars or .NET assemblies into the .AIR bundle.
Have AIR do the following:
1) Verify the digital signatures of these external chunks, using the public key certificate.
2) Have the AIR runtime provide some sort of a sandbox in which to execute these and only these chunks.
3) Have some config utility that points the AIR runtime to the appropriate JVM/.NET/Mono runtime.
4) Have a seamless install that pulls down and installs the JVM/.NET/Mono runtime as needed.
I know this requires a full security & sandbox review, but boy there are a lot of people asking for it.
Oh, and while we’re at it, lets add SerialPort support to AIR! It would be great for little hobby projects, integrating w/ Arduino or other microcontrollers.
Cheers,
Doug
Hey guys,
Artemis isn’t quite defunct. It’s been on the back burner for a while. When AIR is released I’ll be working on a new version with a couple of people who have been testing out some use-cases.
Watch my blog for more info: http://adamflater.blogspot.com
-adam
Hi
I am clearly missing something here, but how does this enable .NET code to be run on a Mac, without the runtime installed?
Sorry if that’s a dumb question!
Marty
>I am clearly missing something here, but how does this enable .NET code to be run on a Mac, without the runtime installed?
It requires that the Mono runtime be installed.
http://www.mono-project.com/
mike chambers
mesh@adobe.com
>Artemis isn’t quite defunct.
Adam, thanks for the update. Ill update the post.
mike chambers
mesh@adobe.com
@Adam, glad to hear that Artemis isn’t dead, it’s just resting!
Cheers,
Doug
@Mike, no problem, thanks for updating.
@Doug, yup… we should talk offline about some of the stuff you’re wanting to do.
Is there a “silent install” flag available for AIR runtime installer?
[...] CommandProxy is a proof of concept by Mike Chambers (Adobe AIR team) that offers a solution to a feature that Ben and I have wanted in AIR…. the ability to talk to native code: Two of the most requested features for Adobe AIR have been the ability to launch native executables from an AIR application, and the ability to integrate native libraries into an AIR application. Unfortunately, neither feature will be included in Adobe AIR 1.0. [...]
>Is there a “silent install” flag available for AIR runtime installer?
Yes. There will be for the 1.0 release.
mike chambers
mesh@adobe.com
[...] Can AIR and .NET live happily ever after? We’ll see after this proof of concept. [...]
I worked on a similar solution Java based (named Jair) because I needed for a project. Unfortunately the project is in standby due to inconvenient AIR limitations with local swfs. But if you are interested in it, just drop me a line.
Nice, but why did you rewrite Artemis in yet another language ? .NET is made portable by Mono, but Java is much better at that…
Adam, glad to see that Artemis will catch up with AIR !
[...] ????? ?? ???????? ??????? AIR-?????????? ???????? ??, ??? ??? ?? ????? ????????? ?????? ??????????. Adobe ????????? ??? ?????????? ? ?????????????, ??????? ???????? ?????? ????????????????. Mike Chambers ????????? ??????? ???? ???????? ? ???? CommandProxy - .NET-??????????, ??????? ??????????? ????? ???????? AIR-??????????, ? ???????? ?? ???? ???????/?????????? ?????????. ?????? ?????????? ???????? ? ??????? ?????????, ???????? ??????????? ?? ?????? ? ?????? ??????????. ???????? ??? ???????? ?????. [...]
[...] Mike Chambers » Blog Archive » CommandProxy : .NET / AIR Integration Proof of Concept Interesting idea. Write a .NET wrapper for launching AIR apps and use it as a proxy between AIR and the OS. (tags: c# air .net lazycoder) [...]
[...] Chambers has build a proof of concept software based on C#/.NET to support the ability to launch native executables from [...]
That’s great. Just wanted to mention about DotGNU, which allows running .net programs without recompiling it for macosx etc.
http://www.gnu.org/software/dotgnu/
-abdul
THis is nice.
I’d have preferred a solution with Python, though. You can use one of the many, many extremely lightweight Python web servers, I run CherryPy in less than 10 megs of memory. Python has great libraries for Integrating with Microsoft’s COM (if you needed a windows only, legacy solution), but on OSX and Windows, Python is great cross-platform glue.
I’ve seen some people doing slick stuff with .NET WinForms based applications that have embeded Python Webserver and an embeded version of Internet Explorer running Flex based screens. This isn’t cross-platform, but they’ve been doing offline/online data syncing from Flex for well over a year with this technique. This is sort-of like a custom AIR, but something that finance guys on Wall Street don’t mind using.
I imagine that if someone put together a light framework for MAC, too, you could expand it further. On WIndows, I build a shell out of .NET WebForms, but on OSX, what would I use to build the shell, straight Cocoa? Anyway the shell just needs to support an embeded web-browser and embeded web-server of some sort and you can then have you cake and ice-cream. Beautiful Flex-based UI, and full access to whatever you want at the OS level.
I’m going to definitely check out what you did here with this Java stuff.
OH, gotta say, THANKS FOR THE SILENT AIR Install. I know see how my custom native installers will work with my vision. THanks for that!
This is really good.
Does the “silent install” have an “easier” licensing?
I’m asking that because to include the flash player silent installation (.msi) some papers/signatures need to be filed before you can include it in a product. I hope this is not the case for the air runtime.
Thank You
[...] Chambers stellt auf seinem Blog eine .Net/Air Integration unter MIT Lizenz zum Download zur Verfügung. Die Lösung basiert auf [...]
Here are step by step instructions for communicating with .net in AIR using WebORB
http://www.themidnightcoders.com/blog/2007/07/weborb-air-edition.html
[...] http://www.mikechambers.com/blog/2008/01/17/commandproxy-net-air-integration-proof-of-concept/ [...]
That looks awesome Mike! Can’t wait to try it out.
[...] the Adobe AIR sandbox By tim Adobe’s Mike Chambers has an article and sample code for calling native operating system APIs from AIR applications, which use the Flash [...]
[...] proof of concept released by Mike Chambers on how to create an interaction between C# / .NET and AIR [...]
[...] are missing in AIR, is the possibility to launch native applications. Mike Chambers now published a proof of concept how to enable this feature. He wrote a CommandProxy that is able to launch applications. The [...]
[...] and integrate it with AIR. For simpletons, I can execute Java code and return values back to AIR. Mike Chambers and Ted Patrick have also done their own implementations, but at the time of concept for my [...]
Isn’t that:
code == joy
or
code := joy
:-)
BTW, thanks for pushing the boundaries…
Hassan
A post on the CommandProxy discussion:
http://adamflater.blogspot.com/2008/01/battle-of-air-and-light-silver.html
I did a similar proof of concept in my own experimentations using flash in early 2007, but in a browser (should work also in air).
The “proxy” was done in Realbasic wich can do pretty much anything with the OS. I wanted to be able to launch automation process (applescript driving photoshop by exemple) from a intranet application.
The communication was done using LocalConnection wich is sometimes difficult to work with, but at least it was not requiring any port listening. We did a similar proof of concept, needing a dedicated port, using Realbasic and a very simple XML-RPC implementation.
The concept could also be done using PHP in a local installation.. but it’s really overkill! :)
[...] Mike Chambers offered a nice solution to this. Theoretically, my workaround is based on LocalConnection and another piece of software which can launch exe files without restrictions. If you really need to run external exe files, and there is no other way of solving your problem, then you will make sure that the user runs that another software before launching the AIR application. Let’s name this another software, Executor. [...]
Hi Mike,
i tried you’re PoC but I have a little problem. The Proxy does not send the authToken to the AIR application. I logged all the args[] into my AIR apps but nothing about this token appears.
I know nothing about .NET and C#. As a workaround I set to FALSE the generation, into the C# code. Any suggestion?
I’m tryed Artemis (with Gonzalo library) but I’ve a problem with framework because when I close my AIR application, Java sature CPU. I’ve tried to contact EffectiveUI team, but they’ve never answered me.
So I’m looking for this library for run an external application (running report manager tool), but I’ve not understand how can it works. Can you give a sample (as applauncher)?
the problem in Artemis is that I can’t stop instance from AS code. In java there is a method getInstance().stop(), but in AIR code I can’t call it…
[...] thanks for Mike Chambers,has build a proof of concept software based on C#/.NET to support the ability to launch native executables from Adobe AIR,it runs on the [...]
Hello Mike,
I have one need - I would like to run my AIR application on windows as windows service, same as I am running my apache or WAMP server, How we can do that ?
I have liked the concept of CommandProxy, really it will be usefull for the scalable development.
I would like to know that is this CommandProxy also alow AIR developer to make thier AIR application to make as windows service?
Thanks
Kishor
[...] Chambers hat sich in seinem Blog bereits Gedanken gemacht (Projekt CommandProxy) wie man diese Beschränkung umgehen könnte, scheint aber selbst nicht so recht davon überzeigt. Alternativ könnte sich auch ein [...]
Hi,
I have liked the concept of CommandProxy, really it is very useful for the AIR developer. I have downloaded the source code, but unable to create a sample application.
Can you please provide me the source code of a sample application which will interact with any native application say notepad.
Thanks
This POC is great example.
For a more robust and complete solution, see Shu…
http://shu-player.com
Sorry guys to spoil the party, but for me it’s just a hack (a nice hack, but still a hack). Adobe should support access to the OS!
In a signed Java Applet you can make a call like:
Desktop.getDesktop().open(new File(”c:/file.doc”));
and the wordprocessor is started (same with pdf, odt, txt, etc.) There is also support for MAIL (open email client, EDIT, BROWSE (open standard browser) and PRINT (without further dialogs;-). It’s pretty cool (and this is just an applet!!!)
I think if Adobe AIR is not given full access and support to the underlying OS in one of its next releases it will miss a big market chance! Right now it has a lot of attention, but…
Hi Mike
This is pretty good!
I’m currently working with a dev team from Argentina, on a presentation software. We currently use Eiffel(which I don’t like, even though I know nothing of it…I’m as AS3 man ;)) for the back-end part of the app, and running a browser with the flash ui.
The app has been in development for around 2 years now, and we have been thinking long and hard about moving over to AIR, but there is some functionality lacking.
Another option was to use something similar to this proof of concept.
Is it possible for us to correspond with you on a consulting level?
Looking forward to your reply.
Yuri
[...] is one interesting post in Mike Chamber’s tech blog about his proof of concept on how to launch native applications from AIR. He has written a CommandProxy and this Command Proxy [...]
This is really interesting way of getting some interoperability between Air and .Net already when there is no other alternative. I have been able to get the POC to work with my Air app and my .Net console app if I enter the authToken manually into the Air app via an input field.
One thing I haven’t understood is how do I get the authToken into my Air application automatically? I thought I would be able to get from the invoke event when the Air application is starting up but it’s always empty, an example can be found on this blog regarding onInvoke:
http://www.jeffryhouser.com/index.cfm/2008/3/20/Accessing-command-line-arguments-in-AIR
It appears that the CommandProxy is setting the authtoken before launching the Air app so hopefully I’m just missing something simple.
TIA,
Magnus
Well this would seems to be a long term issue until AIR would not come up with some secure external application launcher. I think .NET is not a good idea. Why? Because why cant I use .Net as wrapper rather than AIR if I have to use CommandProxy. Artemis is a good idea but having problem of shutdown. Also Java socket servers are good choice for this. I mean a java server would launch the AIR application with certain commands like available port, nature of launch etc. The AIR application would connect via socket and send and receive small commands. In this case lets suppose AIR application will going to be closed, it shutdown the java server via a socket command.
Another solution will be Director. The same thing it would do as a java server and would connect either via local connection or via socket. Well, these are just my ideas. :)
Well sorry for mistake for [I think .NET is not a good idea.]. It would be [I think CommandProxy is not a good idea.]
CommandProxy? Why trying to find the wheel when you can drive Lada (CCCP). One can just create an air application installing with BlazeDS server or Tomcat + WebOrb server (all for Java althought Weborb has a very nice .Net API as well) and then one will have all the advantages of using remote objects. The only thing you should take care of is starting the server before starting the air application, shutting down once connected to a server should not be a problem. In this case your air application would be just a simple wrapper around your RIA UI.
I like the Artemis concept though which I may say is a real concept and this is just a simple hack.
[...] CommandProxy: .NET / AIR Integration Proof of Concept - mikechambers.com [...]
hi,
i think the whole thing is’nt as difficult as it’s discussed. with a little creative thinking we don’t need to compile an extra installer that [...] first installs the AIR application, and then installs the short cut to the command proxy [...].
We have a lot of possibilites by the use of the ByteArray Object. In combination with the access to the users filesystem we can do some tricks (ok, call them hacks too).
When i was looking for a way to create custom shortcuts through air i found this tiny as3 class http://code.awenmedia.com/node/23
it enables you to create .url files which can act as shortcut files too.
this is still not perfect but it works for most cases (on windows). this inspired me for the following workarround:
1) check if this is the first run after a fresh install - we can write a file for that and check if it’s exist.
2.) if this is the first run, than delete the original shortcuts (created by the air installer) and create your own
3.) provide a message to the user, that the initial configuration of the app has been finished and that he just can use the app after a manual restart. set a countdown which automatically closes the app after a short time.
4.) now the user opens the app again, but know by the use of your “custom” shortcuts. because the new shortcuts now point to your CommandProxy.exe - this will start first instead of the air app.
the rest i think is clear …
i have tested this with an .exe file and it worked quite well. think this should work too with with a CommandProxy.exe
cheers!
jan v.
halle
germany
… i’ve missed something:
of cource you have to include your CommandProxy.exe into your air installer in order to work ….
jan
[...] CommandProxy: .NET / AIR Integration Proof of Concept - mikechambers.com [...]
[...] CommandProxy: .NET / AIR Integration Proof of Concept - mikechambers.com [...]
For native access on Windows http://aperture.fluorinefx.com/
[...] CommandProxy: .NET / AIR Integration Proof of Concept - mikechambers.com [...]
[...] For more information on the CommandProxy “Proof-of-Concept”, get it straight from the horse’s mouth. [...]
[...] Adobe AIR?GUI?????????????????????????????CommandProxy?.NET??????????????????????????????Java???????Artemis project???????????????.NET??????????CommandProxy?????AIR?????????????CommandProxy???????????????????????Artemis????????????Artemis?GPL,LGPL??????????????????????CommandProxy ?? AIR?????????????????AIR????????????TCP?WebORB?AMF??????????????????AIR???LocalConnection???????????????????????????????????????????????????????? [...]
Hi guys,
I have successfully used director for my application as proxy and its working fine. Also works well on MAC. I still have question in my mind that should we use .net as proxy?
Well its upto adobe whether they provide a secure launcher or not [:)].