Update 4/30/2008:
NOTE: Flash Player 9.0.124 includes updates that affect the use of crossdomain policy files. For more information, see the Policy file changes in Flash Player 9 article in the Adobe Developer Connection.

This example walks you through the process of creating a library and then using that library as a standard and a cross-domain RSL with an application. It uses the command-line compilers, but you can apply the same process to create and use RSLs with a Flex Builder project. This example first shows you how to use a standard RSL, and then how to use that same RSL as a cross-domain RSL.

Keep in mind that a SWC file is a library that contains a SWF file that contains run-time definitions and additional metadata that is used by the compiler for dependency tracking, among other things. You can open SWC files with any archive tool, such as WinZip, and examine the contents.

Before you use an RSL, first learn how to statically link a SWC file. To do this, you build a SWC file and then set up your application to use that SWC file.

In this example you have an application named app.mxml that uses the ProductConfigurator.as and ProductView.as classes. The structure of this example includes the following files and directories:

project/src/app.mxml
project/libsrc/ProductConfigurator.as
project/libsrc/ProductView.as 
project/lib/
project/bin/

To compile this application without using libraries, you can link the classes in the /libsrc directory using the source-path option, as the following example shows:

cd project/src
mxmlc -o=../bin/app.swf -source-path+=../libsrc app.mxml

This command adds the ProductConfigurator and ProductView classes to the SWF file.

To use a library rather than standalone classes, you first create a library from the classes. You use the compc compiler to create a SWC file that contains the ProductConfigurator and ProductView classes, as the following command shows:

cd project
compc -source-path+=libsrc -debug=false -o=lib/mylib.swc ProductConfigurator ProductView

This compiles the mylib.swc file in the lib directory. This SWC file contains the implementations of the ProductConfigurator and ProductView classes.

To recompile your application with the new library, you add the library with the library-path option, as the following example shows:

cd project/src 
mxmlc -o=../bin/app.swf -library-path+=../lib/mylib.swc app.mxml

This links the library at compile time, which does not result in any benefits of externalization. The library is not yet being used as an RSL. If you use the new library as an RSL, the resulting SWF file will be smaller, and the library can be shared across multiple applications.

Now you can recompile the application to use the library as an external RSL rather than as a library linked at compile time.

The first step is to compile your application with the runtime-shared-library-path option. This option instructs the compiler to specifically exclude the classes in your library from being compiled into your application, and provides a run time location of the RSL SWF file.

cd project/src 
mxmlc -o=../bin/app.swf -runtime-shared-library-path=../lib/mylib.swc,myrsl.swf app.mxml

The next step is to prepare the RSL so that it can be found at run time. To do this, you extract the library.swf file from the SWC file with any archive tool, such as WinZip or jar.

The following example extracts the SWF file by using the unzip utility on the command line:

cd project/lib
unzip mylib.swc library.swf
mv library.swf ../bin/myrsl.swf

This example renames the library.swf file to myrsl.swf and moves it to the same directory as the application SWF file.

The next step is to optimize the library.swf file so that it does not contain any debug code or unnecessary metadata. The following example optimizes the SWF file by using the optimizer tool:

optimimzer -keep-as3-metadata="Bindable,Managed,ChangeEvent,NonCommittingChangeEvent,
Transient" -input bin/myrsl.swf -output bin/myrsl.swf

You now deploy the main application and the RSL. In this example, they must be in the same directory. If you want to deploy the myrsl.swf file to a different directory, you specify a different path in the runtime-shared-library-path option.

You can optionally run the optimizer tool on the myrsl.swf file to make it smaller before deploying it. For more information, see Optimizing RSL SWF files.

To use the RSL as a cross-domain RSL, you add a crossdomain.xml file, a failover RSL, and its crossdomain.xml file to the option, as the following example shows:

cd project/src
mxmlc -o=../bin/app.swf -runtime-shared-library-path=../lib/mylib.swc,
    http://www.my-remote-domain.com/rsls/myrsl.swf,
    http://www.my-remote-domain.com/rsls/crossdomain.xml,
    http://www.my-other-remote-domain.com/rsls/myrsl.swf,
    http://www.my-other-remote-domain.com/rsls/crossdomain.xml,
    Main.mxml

Next, you create a crossdomain.xml file. If the domain that are you running the Flex application on is my-local-domain.com, then you can create a crossdomain.xml file that looks like the following:

<cross-domain-policy>
    <allow-access-from domain="*.my-local-domain.com" to-ports="*"/>
</cross-domain-policy>

You now deploy the main application and the RSL. This time, however, the RSL is deployed on a remote server in the /rsls directory. You must also ensure that the crossdomain.xml file is in that directory. Finally, you must ensure that the failover RSL and its crossdomain.xm l file are deployed to the other remote domain.