The video showcases some of the planned features for FluorineFx 1.1 (and Visual Studio integration)
Note: in the video, the top project in the solution browser is a Flex Builder project wrapper for Visual Studio.

Video shows how to attach to Visual Studio’s Development Web Server (to a running web application) for debugging purposes.
That is when you don’t start your web application in debug mode and you need to attach the debugger.

If you are using IIS then attach to the aspnet_wp.exe executable.

Video showing how to start with FluorineFx and Microsoft Visual Studio 2005

Disclaimer again: No swfs, libraries, Air runtime, tools were harmed during the making of this application.

Aperture employs a Win32 user level hooking technique called export forwarding. In the current version the msi.dll component is used that contains functions exported for Microsoft Installer packages.
The proxy dll creates function stubs that do nothing but jump to the exported addresses in the original dll, so all calls are delegated to the original msi.dll.

When the AIR application starts the NT DLL Loader sets up the dll initialization list from the static imports found in the PE header. If the proxy msi.dll exists in the application’s folder it will be loaded from this location. The proxy dll then will load the original dll (from the Windows system folder) and forward all calls to the original component.

Once a specific call is intercepted the proxy dll starts the Aperture system, preparing the LocalConnection communication with the current AIR application. And when your AIR ActionScript code starts running Aperture is already listening for commands.

To put it simply: the above stuff means that if the proxy dll is in the AIR application folder and you are on Windows then you have access to the Aperture system. The AIR application will work just fine on any other OS but without native library access.

COM, IDispatch anywhere

The Aperture system dispatches messages from AIR to objects that support OLE Automation (IDispatch). This is how COM “reflection” works. Please note that the provided libraries (apsystem, apimaging, apoutlook) are also ATL COM libraries but Aperture has the ability to work with them without registering their type library.
This is to avoid the necessity of a special installation to register the COM components so an AIR application using the framework will not need any special installation step.

All the libraries provided are statically linked and there are no external dependencies that must be satisfied.

And what about .NET?

Calling .NET assemblies is also possible via COM Interop but currently there is no way to distribute these assemblies without proper registration (you have to go through registration with the RegAsm tool).

FluorineFx Aperture Framework
You can find the framework here

Disclaimer: No swfs, libraries, Air runtime, tools were harmed during the making of this application.

You all know by now the popular request to launch native executables from an AIR application.

Note, this demo is an experiment/hack that shows how AIR can be extended with native Windows libraries. It does not require having the .NET framework installed and works only on Windows (of course the application will run on other operating systems too where AIR is supported but without native library access).

After installing the application you can test 2 things: querying the operating system info (will use the GetVersionEx kernel32 function) and performing file operations with the ShellExecuteEx Windows API.

Give it a try.

Update: Part II