views:

1103

answers:

4

Using Silverlight 3, I noticed that System.Xml.Linq.dll was added to my XAP file, increasing the size from 12 to 58 k, so I checked the box 'Reduce XAP Size by using application library caching'.

Publishing the app to IIS, then loading it with Web Dev Helper enabled, I see that when I open the app, the XAP file at 12k is loaded, then the System.Xml.Linq.zip is loaded at 46k, for a total of 58k. Whenever I refresh the main page of the app, the same files are loaded into the browser. If I uncheck the 'Reduce..." box, then re-publish the app to IIS, one XAP file at 58k is loaded whenever I load the application.

How is one method different from or better than the other? I could see the advantage if the dll were somehow saved on the client computer removing the need to download it each time the app were opened.

Thanks Mike Thomas

+2  A: 

A browser caches by URL, so by splitting your application into a part which changes frequently and a part which will probably stay the same for a long time (the Linq part) and which might be shared between applications even, you save some download.

But it depends on the exact situation (frequency of change, location of 'generic' DLLs, etc.) whether it really helps.

Rutger Nijlunsing
This is strange to me. If the dll is cached the first time the application is loaded, then why is the dll zip file uploaded again when I click in the 'Refresh" icon in IE? I would think that when the MainPage page is reloaded by a refresh, the app would see that the dll was already cached and would not request it from the server, but according to Web Dev Helper, it is being requested and loaded again.
+1  A: 

The whole reason for keeping XAP size small is so that your application loads as quickly as possible. This is important: even on a faster connection, a bloated XAP can take extra seconds to load, which can be long enough for your users to leave your site.

While Linq is only accounting for 46KB, there are other cases where this can make a bigger deal. For instance, the SyndicationFeed class makes it really easy to handle RSS and ATOM feeds, but it weighs in at 114KB.

Application library caching helps in two ways:

  1. It allows for sharing common DLL's between applications, so if another application has already pulled down a system DLL, your app can just reference it.
  2. It allows your application updates to be smaller, since the framework DLL's won't change betwen XAP versions.
Jon Galloway
A: 

Thanks Jon,

I understand what you and Rutger are saying, but I don't see how this is working in practice as I mentioned in my comment above.

When I go to the URL which opens the Silverlight app, I can see the request going from my browser (in Web Dev Helper) to the client for both the application dll and the framework ddl(s). Both files, among others, are sent from the server to the client.

If I close the Silverlight app, then go to the URL and reopen it, the same process is repeated. If I am on the MainPage and click the refresh button, both files are requested and sent again.

Are you saying that once a framework dll is sent to client browser, it remains there even after the app is closed, so that the next time the app is opened on the browser the framework dll will not have to be uploaded again?

This seems like an important question, because I can imagine several hundred k of framework dll's alone.

Thanks Mike Thomas

A: 

The difference is that when dll's are outside of the XAP file even though browser asks for those files webserver responds with 304 Not Modified HTTP response. By default browser will not request for those files to be downloaded again. This obviously saves time especially when project references "heavy" libraries (ie. Telerik ones can be quite large in size)

Hope this helps someone.

Adrian