Distribution via MXP

I suspect an awful lot of you who read this article have used the Exchange Extension Manager. Some of you may have it installed and never used it. Regardless if you have ever wondered how to package up your files for distribution via this format then this article should help you on your way.

Please note that this will be Flash / Flex component centric so certain tags and functionality will not be covered off for the other applications that support the Extension Manager. For a thorough breakdown and full documentation you can access it on the Adobe site via the links section at the bottom of this article. To create an MXP for distribution you first need to create the .mxi (mixy) file – this is read in by the packager and details what is required by the .mxp in terms of files and application need to take advantage of the extension package (.mxp).

What does an .mxi file look like?
If you’ve never seen an .mxi file don’t worry – it’s just XML and fairly easy to follow to boot. So to create one you don’t need an special tools – a simple text editor will suffice. However, if you’re not comfortable hand cranking the file there are a couple of applications in the Links section that you can try out to see if they suit your needs.

Below is the .mxi file that I used for the FileTransferConnector component .mxp

Lets break this down into its main elements. First of all we have the extension descriptors. As you can see it’s fairly clear what each element is responsible for, our root node <macromedia-extension> deals with the name, version and type of extension we are installing. It also allows us to set whether the extension requires the application to restart to operate correctly. One thing to note here is that the type of extension is flashcomponentswc – this isn’t in the documentation but for SWC based components you need to add this not the old type of “flashcomponent”. Next we have the author details – obviously keep it simple, I added my domain purely for a reference perspective if someone got my extension from a colleague and didn’t know where it came from (it shows up in the Extension Manager main window).

The last threee elements in this block deal with the extension manager directly, we have the actual product that is required for the extension to be installed on the users machine. No Flash, no extension in this .mxi’s case. A description of the extension that will appear in the lower window of the Extension Manager, and finally a node named ui-access. This node is solely for copy pertaining to the extension and how to access / utilize it from within the desired application. It too appears within the lower window of the extension manager, but I suspect it can be consumed in additional ways and therefore the rigid adherance as to what it can contain.

As you may have noticed these are ![CDATA[]] entries so you can put basic HTML formatting inside the description, but don’t get carried away anything above and beyond <p> and <br> as font formatting or hyperlinking isn’t supported.

The lower section of the .mxi file deals with any license you are apply to the extension and where you actually want to put all your files on the users machine. This particular license is one for a creative commons style license. If you’re wondering where this appears you’ll find it at the very bottom of the license dialog that opens when you first start the extension installation in the Extension Manager. Again you can use basic HTML formatting inside this node.

Now in certain situations you may not wish to create a ‘suite’ extension but need to install additional files. In my opinion that’s OK as long as the user is made aware that additional files are going to be installed that may indirectly relate to your extension, but don’t think of it as a short cut to making a suite, if you are installing more than one primary file onto the users machine use the extension type of ‘suite’. In the .mxi file below you’ll see I’m installing not only the SWC, but the class file as well as, (in this particular components case), an additional server script and an example file so the end user can see it operating.

In the example code you can see that I have set various paths for the files I wish to install, firstly we have the actual component SWC, next we have the class file for this component – including this means that developers can utilize the createClassObject() as well as the simpler createObject() call. In addition to these a sample fla and php file are included as well as a copy of the license that applies to this particular release (not required in most cases but included for completeness).

As you can see we use a system variable, $Flash, to grab the correct path to the Flash installation on the users machine. This isn’t the directory that Flash was installed into but the configuration folder that is created the first time you run Flash. Something to concider here is you cannot easily create a folder structure outside of this path – nor would it be a secure or proper thing to attempt, but just incase you were interested.

If you’re still not sure what I mean by $Flash representing the system path to the Flash folder I have detailed them below. So on a Windows installation it would be:

  • Boot Drive:\Documents and Settings\(username)\Local Settings\Application Data\Macromedia\(Flash MX 2004 or Flash 8 )\(language)\Configuration\

On a Mac it would be something along these lines:

  • Macintosh HD/Users/(username)/Library/Application Support/Macromedia/(Flash MX 2004 or Flash 8 )/(language)/Configuration/

From there we can path our directories as required (note the use of forward slashes in our path names – even on a windows machine). So to put our SWC in a specific folder within the Components folder on the users machine we code it like so:

  • $flash/Components/FlashGen.Com

Likewise if we wish to create any other folders we can do so utilizing the same process. One thing to bare in mind when testing your .mxi file is that any folders you create on the users machine do not get removed when they uninstall the extension. This isn’t a real problem once the extension is released but can give false positives while testing your extension.

Testing the .MXI
To test you .mxi file you don’t need to do anything spectacular – on most installations the Extension Manager associates itself with .mxi and .mxp files or their OS dependant equivalent. So a simple execution of the file should start the installation of your extension – or throw errors if there is something wrong. Full details on how to create and install a .mxp can be found in the PDF detailed below.

Hopefully this will at least set you on the path of least resistance when it comes to packaging and distributing content for Adobe products.


Here are a list of applications to get the extensions on your machine or help you create your .MXI, .MXP files:

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *