Silverlight XAPs and Web Sites- Page 1
       by kirupa  |  16 April 2008

When you build a Silverlight application, especially if you use Blend, the most common way is to create a new Silverlight 2 Application. More than likely, your entire solution might just be a single Silverlight project:

[ by default, you will probably just create a Silverlight project...and that's fine! ]

There is nothing wrong with setting up a Silverlight project this way. Debugging works. Testing works. Everything seems fine. Actually, everything is fine.

Only when you start to integrate your Silverlight app as part of an existing web site, or if you are planning on lazily loading content on demand, the convenience of the above setup may turn into a nuisance.

Everything Gets Compressed into the XAP
Often times, your Silverlight content will involve large pieces of external content, media files, Deep Zoom images, etc. When you incorporate all of your content into your Silverlight project, they get compiled and compressed into the XAP by default. These various pieces of content may seem like individual/loose files right now, but when you build, though, all of these loose pieces of content get compressed and placed inside your XAP:

There are cases where you probably want that. Having items inside the XAP means that you get the free preloader that automatically displays when you are trying to display your content. The downside is that, if you have content that you want loaded on-demand such as videos or photos in a photo gallery, you don't want such content to be downloaded initially. You wouldn't want such content to be embedded inside the XAP either.

Persisting Changes to the HTML File
Another subtle but possibly more annoying issue is that, in a Silverlight-only solution containing a single Silverlight project, you do not have the ability to save the HTML file that will be hosting your Silverlight XAP. Each time you build, your changes get overwritten. That means that if you were to alter the default HTML page containing your Silverlight content, the next time you build, those changes you made would be overwritten.

The Solution: Web Site Projects 
To help you out of this conundrum, you have Web Site projects. A Web Site project is the equivalent of a web site directory where loose files can be placed. What makes this useful when using Visual Studio, is that if you have existing Silverlight content, VS will ask if it can link your Silverlight output, known as a XAP file, to a location on your Web site project itself.

That probably seems a bit confusion, so hopefully the following image gives you a basic idea of how your solution would be set up:

Notice that when you build, you create a XAP file. This XAP file gets copied into your Web Site directory where you can access all of the content inside your Web site easily.

This solves all of the problems we mentioned earlier. Because your Silverlight project does not contain any content you would not want inside your XAP, your XAP only contains what you feel is relevant. Any content that you want to use but don't wish to embed in your XAP, you can simply place them in your Web Site Project instead!

Also, your web site project will come with a preconfigured HTML file that loads and displays your XAP. Since this file is located in your Web site project itself, you building your Silverlight project will have no effect on any changes you made to your HTML file inside your Web site project.

Despite this long introduction. Creating your own Web Site project is not tricky at all. Let's look at how to do that on the next page.

Onwards to the next page!

1 | 2 | 3