So you've created something cool in Silverlight but your XAP file is bigger than you would've hoped. What can you do about it?Well there are tips to be found on the internet. Some say that recompressing the XAP file with something like WinRAR on its "best" compression setting will help. But that was in the Visual Studio 2008 / Silverlight 2 days. Now if you're building a Silverlight 4 app in Visual Studio 2010 it's already going to be compressed about as heavily as is possible. So I'm going to talk about other effective techniques that will help you today.Tips1.) Reduce XAP size by using application library caching (not available for out-of-browser applications). Check this option in Visual Studio 2010 and when your project is built there will be extra files automatically generated. So you'll have to upload your XAP file and any auto-generated ZIP files to the same directory. The generated ZIP files contain any external assemblies that your XAP require. Behind the scenes this relationship is automatically maintained with the AppManifest. This feature is pretty cool and very easy to use. You should note, however, that the whole idea behind it is caching. And so it speeds up requests from repeat visitors, but in practice it doesn't do a thing to speed up the experience for a new visitor. Read more about this feature from Microsoft.
2.) Make sure that you're including references to assemblies that you actually need and nothing more. Sometimes you'll need a reference to an assembly but you don't want it set to "Copy Local", as that adds to the XAP. Visual Studio 2010 is usually good about automatically setting "Copy Local" when appropriate. For example, System.Windows.Controls is not part of the runtime (it's a part of the SDK). Visual Studio knows this and when you add System.Windows.Controls to the project it automatically sets "Copy Local" to true. But when in doubt about an assembly reference, try setting "Copy Local" to false and see what happens. If your application builds and runs fine, then you're good. 3.) If you have a need for just one of these controls below, then download and use it rather than including the entire System.Windows.Controls assembly:
I ripped those controls out of the Silverlight SDK a couple weeks ago, and created individual projects out of them. If you only needed the Grid Splitter, for example, then you could save around 60 KB by adding it to your project instead of the entire System.Windows.Controls.dll. 4.) Set up content expiration in IIS. So far we've just been concentrating on the XAP file itself. It's easy to forget about server configuration. Read more: SilverlightXAP Blog
2.) Make sure that you're including references to assemblies that you actually need and nothing more. Sometimes you'll need a reference to an assembly but you don't want it set to "Copy Local", as that adds to the XAP. Visual Studio 2010 is usually good about automatically setting "Copy Local" when appropriate. For example, System.Windows.Controls is not part of the runtime (it's a part of the SDK). Visual Studio knows this and when you add System.Windows.Controls to the project it automatically sets "Copy Local" to true. But when in doubt about an assembly reference, try setting "Copy Local" to false and see what happens. If your application builds and runs fine, then you're good. 3.) If you have a need for just one of these controls below, then download and use it rather than including the entire System.Windows.Controls assembly:
Calendar
Date Picker
Grid Splitter
Tab Control
I ripped those controls out of the Silverlight SDK a couple weeks ago, and created individual projects out of them. If you only needed the Grid Splitter, for example, then you could save around 60 KB by adding it to your project instead of the entire System.Windows.Controls.dll. 4.) Set up content expiration in IIS. So far we've just been concentrating on the XAP file itself. It's easy to forget about server configuration. Read more: SilverlightXAP Blog
Posts
0 comments:
Post a Comment