Share via

Deploying Silverlight Applications

Deploying a Silverlight application that is built with the Composite Application Library is no different from deploying a regular Silverlight application. An extra consideration is to make the remote modules available on the Web server if the application uses remote modules.

Silverlight XAP Files

Silverlight applications are downloaded by the browser in XAP files. These XAP files are essentially .zip files that contain an assembly manifest file and one or more assemblies.

Preparing Your Web Server to Host Silverlight Applications

Silverlight applications can be hosted on most types of Web servers, like Internet Information Server (IIS) or Apache. However, most Web servers are usually configured to serve only a short list of well-known file extensions. To allow Silverlight applications to be served from your Web server, you have to allow the MIME types in the following table to be served.


MIME type





Deploying the Application

To deploy a Silverlight application and the modules that are remotely loaded, the XAP files must be made accessible on the Web server. There are several ways to accomplish this:

  • You can manually copy all the XAP files to a public folder on the Web server.

  • You can create a Web project or a Web site on the same solution that contains the Silverlight application and add a reference to all the projects in the solution that generate a XAP file as output (usually the main application and the remote modules) as Silverlight Applications, as shown in Figure 1. This creates a new folder named ClientBin and copies the generated XAP files. These files will be kept in synchronization by Visual Studio. Finally, the Web project or Web site must be deployed on the Web server.


    Figure 1

    Adding the remote modules as Silverlight applications


    To avoid cross-domain call issues, the remote modules' XAP files should be located on the same domain as the main application; when deployed like this, the Ref property on the ModuleCatalog should be a Uniform Resource Identifier (URI) relative to the main XAP file location on the Web server.

Optimizing XAP Files for Download Speed

By default, any non-system assemblies that you reference will be added to the XAP file generated by Silverlight applications. If you want to optimize your XAP files for download speed, this behavior may not be efficient for some of your modules' references.

Consider the following example. You have created an application with several remote modules. Each module gets its own XAP file. You have also created a shared Common assembly that contains shared services, common interfaces, and so on. Each module references that common assembly. By default, each XAP file will now also contain the Common assembly; this makes the XAP files larger than they need to be.

To solve this, change the references to the Common assembly in all of the modules by setting Copy Local to false. This ensures that the Common assembly is not added to the XAP files.

When deploying Silverlight applications created with the Composite Application Library, some common assemblies that can typically be excluded from the XAP files include Composite and Composite.Presentation assemblies and infrastructure assemblies, among others.


For more information about optimizing XAP files, see How to: Prepare a Module for Remote Downloading.

More Information

For more information about deploying Silverlight applications, see the following resources:

Home page on MSDN | Community site