I bet you've never seen this before... I wrote a C# program that communicates with Flash over LocalConnection.
I can't give you a live demonstration because I don't want any to decompile the C# executable, but here's a link to a captivate demo showing it in action: Using LocalConnection to send data between C# and Flash.
In the demo I'm only sending string values, but you can send just about anything over LocalConnection. On the Flash end, just use LocalConnection like you normally would. On the C# end, I've created a LocalConnection class that behaves in a similar manner. In Flash I can call a C# method directly in this manner.. it's very handy actually.
Currently I have no plans to release this code (I'd like to get MM's blessing first before just putting it out there). If you know anything about operating systems and know how IPC works you can probably figure it out on your own though.
This opens up a whole new world of combining Flash and .NET. Next steps are to flesh out a decent API (mine is a little rough around the edges since the above demo was just a proof of concept), and then port the code to Linux and OS X as well. LocalConnection behaves differently on each operating system because, well, each OS does IPC in a different manner. The quest for the cross-platform Flash projector continues...

40 Comments
Amazing!
All the times I saw Flash integrated with a Windows app was through an embedded flash.
This is pretty interesting, you could build applications as windows services and build the frontends with Flash.
I'm looking fordward to see this running!
Regards
Pablo Costantini
Posted by: Pablo Costantini | March 17, 2005 9:31 AM
That is very cool. For me I find it exciting to extend Flash in a similar way.
Posted by: Mark | March 17, 2005 9:36 AM
Wickedly done, Darron. That is really excellent.
Can you communicate with that from a .swf on a site (eg: versus a flash projector)? I'm assuming it's no different, really - more of a question of how the C# app would connect to the .swf.
It'd be nice to have a C#/.NET debugger interface that you could connect to, instead of the standard Flash projectors that people have been floating around...
Posted by: Jason Nussbaum | March 17, 2005 10:00 AM
Jason - yes, you can use this method to talk to any LocalConnection imaginable (from StandAlone playuers, from .swfs in a browsers, and even from .swfs in their own projectors). As long as you know the LocalConnection name you can connect to it.
Actually, you don't *need* to know the LocalConnection name... in fact, I can write a program to look at all of the open LocalConnection's on my system and inspect the data going in and out of them.
So, if you use LocalConnection to send like passwords and other sensitive information, think twice. Make sure it's encrypted -- the information you send over LC is not as secure as you might think.
And also note, this is not limited to .NET. In C# I'm doing a lot of "extern" calls to kernel32.dll. I could've written this is C++, but chose C# because I think it better as a language and easier to develop in. On Linux and Mac I'll be using C++, or maybe Java and JNI.
This example could be converted into a runtime debugger pretty easily. Instead of trace, you would just create an lc and send the data to C#. Like.. out.send("debugger", "logError", theErrorData). That's a pretty good practical application.. let me think about that one (and trying to code it via Java). I doubt I'll have the time to write it though.
Posted by: darron | March 17, 2005 10:18 AM
The idea of using the LocalConnection for inspecing objs and sending them to a Windows app sounds good.
I've made a Logger API some time ago that allows you to inspect objects and movieclips at runtime and send that information to multiple outputs. One of these outputs uses a LocalConnection obj and a Flash console. An example can be found here:
http://www.luminicbox.com/dev/flash/log/example.htm
The main issue i'm having right now is handling a large list of debugging items. A windows version of the console could improve performance and add some nifty features.
Maybe you can test something out, the logger API and flash console can be download from here:
http://www.luminicbox.com/dev/flash/log/luminicbox.log.zip
More information (in spanish) can be found here:
http://www.luminicbox.com/dev/flash/log/
he code, comments and class documentation is written in english.
Regards!
Pablo Costantini
Posted by: Pablo Costantini | March 17, 2005 10:42 AM
now the real challenge would be to write a crossbrowser projector using localconnection to exchange data (maybe in python?).
if only macromedia would say yes...
Posted by: claus wahlers | March 17, 2005 10:44 AM
Looks interesting :)
I'm using fscommand/setVariable for a desktop .NET application with embedded Flash UI and I wonder what are the advantages of LocalConnection in that case.
Posted by: Rostislav | March 17, 2005 10:45 AM
"crossbrowser projector"
d'uh.. ;)
should read crossplatform of course
Posted by: claus wahlers | March 17, 2005 10:47 AM
Wow, I have recently run into a situation where we had discussed the feasability of doing exactly what you have accomplished. Our problem involves having a web based application communicate with a locally running (non-flash) piece of software. I know you said you would not be releasing the code any time soon, but is there any further information which you could divulge about what was involved in getting this to work?
I am mostly concerned with how you feel about the long term feasability of your solution, as this was an approach we were considering. Does it work smoothly? Do you feel like it's a hack that would fall apart with new versions of the flash player or with different configurations of windows? Do you believe the OSX conversion is going to be difficult?
We were planning on trying a socket connection first and seeing how that pans out, but a localconnection may be better.
Posted by: Noel B | March 17, 2005 10:50 AM
@Rostislav - The advantage of using LocalConnection is that you can send data better and easier. With fscommand and sockets for external communication you have worry about serializing your data and such. With LocalConnection you just send the native object. I can send a native array from C# and Flash will pick it up as an array - no conversion necessary (it's part of the LC protocol).
@Claus - a Python port might be already underway..
@Noel - Long term feasability is not an issue. In Player 6 and 7, things will always work. In Player 8, LC might be implemented differently, but I don't envision it becomming not usable. There will have to be some coded added to check the version and make sure it's compatible. It works very smoothly, but right now it's kind of hacky because this was just a proof of concept. If I take time to flesh out a good API I would feel better about the stability. The OS X and Linux conversions should not be difficult at all, it's really just a matter of semantics. I know enough about IPC to know where to start looking, and the *concept* should be the same corss platform, with the implementation varying only slightly to support the different operating system system calls.
As to LC being better than a socket - the automatic serialization of data in LC beats sending text over a socket any day.
Posted by: darron | March 17, 2005 11:07 AM
You could make your own version of Central with this ;)
Good stuff.
Posted by: Ash | March 17, 2005 11:09 AM
I don't know how LocalConnection works, but isn't this just a socket connection and sending commands back and forth (and you figured out the protocol)?
Posted by: Manish Jethani | March 17, 2005 11:30 AM
Manish, no it's definitely not a socket - it's a lot more complicated than that. We're talking low-level operating system stuff here...
Posted by: darron | March 17, 2005 11:43 AM
so did you get a way through mutex & memory-mapped file...
just a guess...
-abdul
Posted by: Abdul Qabiz | March 17, 2005 2:17 PM
Sick bro! Just sick!
-erik
Posted by: erikbianchi | March 17, 2005 2:21 PM
Wow ! Thats great ! I tried to figure out once whether it was done with Window messages, but did not detect any broadcasts when this kind of connections happened. Should I check again whether it is done with Window Messages or should I better try to figure out whether is is done by DDE ?
regards
Roberto
Posted by: Roberto | March 17, 2005 2:27 PM
Awesome Darron! This make a lot of new things possible - great work, I know that can't have been easy : ).
Posted by: Robin Debreuil | March 17, 2005 2:56 PM
@Roberto - no, it's not Windows messages and it's not by DDE.
@Robin - Yeah, it was a lot of fiddling trying to get it working. Reading data was kind of the easy part.. the *very* hard part was figuring out how to write data to the LC. That part alone I was stuck on for an incredibly long time. It actually came down to dumb luck (hey, the best inventions are usually by accident anyway, so maybe thats a good sign).
The possibilities for this are tremendous... It's so easy to use, and it's awesome to be able to call Flash methods directly from C#, and C# methods directly from Flash.. passing data between them is a breeze.
Posted by: darron | March 17, 2005 3:12 PM
Now I hope MM has nothing against the reverse engeneering of LC (and will continue with LC in the next Flashplayer). In case of AMF, they were very tolerant, and OpenAmf was competing directly with their Remoting Product. But here I think MM has nothing to loose, but a lot to gain.
And I even more hope that you are going to reveal more info about how you did it or at least give us one more hint to make it a bit easier to figure it out ourselves.
Posted by: Roberto | March 17, 2005 9:41 PM
I sincerely hope that something comes of this. This is immensely useful! We can stop worrying about data marshalling and get on with the cool stuff! This is Flex Remoting (easy as pie) for the desktop!
...
Hmm. Unfortunately for us, that sounds like something worth charging for.
Fingers crossed, thumbs held!
Posted by: Robert | March 18, 2005 3:42 AM
I think the people at 2entwine used Python to embed flash: http://www.2entwine.com/
their projector installs on MS, Linux, OsX
Posted by: pim | March 18, 2005 6:18 AM
WOW, I have used fs command to communicate with my cocoa app, but will LocalConnection work better? Thanx
Posted by: JR | March 18, 2005 8:40 AM
I've been looking through what you've said, I've got the names of the mutex and the shared memory, but any further than that and I'm stuck. I've got some code (C++) that looks like it should push a block of data into the right place and then signal the swf app to read it, but it doesn't work, I can't even get data from the swf app. Basically I'm stuck, what are the chances of any further hints?
Posted by: Rob White | March 21, 2005 11:25 AM
That's fair enough. I'll just keep plugging away with what I know.
Posted by: Rob White | March 22, 2005 4:01 AM
As the Swf format is an open format why should macromedia have a problem?
Posted by: Mike M | March 23, 2005 4:27 AM
The swf format is open, yes, but the internals of how the Player implements LocalConnection is not.
Posted by: darron | March 23, 2005 6:48 AM
Well now that you started the discussion it will eventually be revealed.
If I were you I would develop a component and sell it. If you don't someone else will and you will lose your first to market advantage.
Posted by: Riley | March 24, 2005 4:54 PM
it sounds verry nice.
but would it work on a pda?
for my final work i need to
send data (strings or is possible an array)
from c# to flash but i can't figure it out
kind regards
dennis
Posted by: Dennis Simpelaere | April 13, 2005 6:46 AM
it sounds verry nice.
but would a localconnection
work on a pda?
(i don't know much flash)
im a master student and i'm searching
for sometway to communicate to flash
but i can't find it.
kind regards
dennis
Posted by: dennis simpelaere | April 13, 2005 6:48 AM
I figured it out, but I am having trouble deserializing the method arguements if they are anything other than strings.. did you use .net deserialization, or create a custom class to resolve the arguements into .net types? I thought I had it figured out, as each block has a byte specifiying the length of the block -- until I started sending arrays and integers..
Posted by: Ben Coddington | May 29, 2005 10:17 AM
Hi,
Very nice work.
Did you ever get Macromedia's Blessing? I have just started to pursue a very similar line and would like to get a few things answered before getting any deeper.
Thanks
Posted by: dix | July 6, 2005 6:19 AM
No, I still haven't received an "OK" to share the code I used to make this happen. :-(
Posted by: darron | July 6, 2005 1:42 PM
great work and bad news ! :(
Posted by: Francis Bourre | July 6, 2005 5:06 PM
Great post!!.. Have you tried Flash with .NET 2.0 beta?
Lot of changes between 1.1 vs 2.0 in .NET..
Posted by: Srini | July 14, 2005 10:41 AM
Given that OSFlash has already released this information for C, I hardly think a C# implementation is going to break any hearts at Macromedia.
http://osflash.org/doku.php?id=localconnection
Posted by: Bill | August 24, 2005 2:26 PM
With ExternalInterface in Flash Player 8, there's no need to play with local connection like this anymore. :-)
Posted by: darron | August 24, 2005 2:43 PM
real good but how can i use the same on mac? Can any one help me for the intigration of swf with cocoa app .
Thanx for reply
Posted by: Anonymous | August 26, 2005 11:25 AM
So could you share that code now?
Someone else did:
http://codeazur.com.br/stuff/accessLocalConnection.txt\
http://osflash.org/localconnection
Posted by: Me | March 7, 2006 9:54 AM
Honestly, I don't believe it. That's not a working demo. It's just a flash animation.
Posted by: 216.161.203.65 | March 24, 2006 4:12 PM
It's not a Flash animation, it's a Captivate demo. :-)
As I said before, ExternalInterface replaces the need to hack around with Local Connection like this. I wouldn't recommend using an LC approach to SWF Container communication.
Even though LC has been documented on OSFlash, I'm not planning on releasing my C# code for it now or in the future. There are better methods for communication, and I wouldn't recommend trying this approach anymore today.
Posted by: darron | March 24, 2006 4:50 PM