How to Deploy Silverlight Applications

You can deploy a Silverlight application to a Web site, as you would an ASP.NET MVC

application. However, you'll need to ensure the MIME type and policy is in place to

ensure the application will run outside of your development environment.

 

If you're running IIS 7, Silverlight will already be set up. However, if you're

deploying to an IIS 6 server, you must set the MIME type for *.xap files to application/

x-silverlight-app as described in the following steps:

 

1. Open Administrative Tools | Internet Information Services (IIS) Manager.

2. Under Web Sites, in IIS, right-click on the Web site for your Silverlight application and

select Properties.

3. Click the HTTP Headers tab, click MIME Types, and click New.

4. Type .xap as the Extension and application/x-silverlight-app as the MIME type.

Click OK three times to close all windows and close IIS.

Additionally, you must have a policy file in the root folder of your Web site. There

are two types of policy files you can use: crossdomain.xml or clientaccesspolicy.xml.

 

The crossdomain.xml policy was created for Adobe Flash applications and can be used

with Silverlight applications too. Here's an example:

 

<!DOCTYPE cross-domain-policy

SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

<allow-access-from domain="*" />

<allow-http-request-headers-from domain="*" headers="*" />

</cross-domain-policy>

 

When designing Silverlight, Microsoft recognized that the crossdomain.xml

file wasn't flexible enough and added support for another type of policy called

clientaccesspolicy.xml. Here's an example:

 

<?xml version="1.0" encoding="utf-8"?>

<access-policy>

<cross-domain-access>

<policy>

<allow-from http-methods="*">"

<domain uri="*"/>

</allow-from>

<grant-to>

<resource path="/" include-subpaths="true"/>

</grant-to>

</policy>

</cross-domain-access>

</access-policy>

 

This clientaccesspolicy.xml listing allows all domains to access all site content that

isn't already secured by other means. You can restrict access by replacing the * in the

domain uri with an allowable domain. Further, you can replace the resource path with a

path on the site to restrict access to specific folders. Add more policy elements to this file

to add more domains and paths.