Friday, October 08, 2010 9:06 AM
Hello, SL development team and all!
I had write a simple Silverlight 4 application with Datagrid and call web-service to get data from the asp.net Server.
After build the application, the XAP size was about 700K bytes. It's about too large, I think. Not all the people in the world have their computer connected to the internet with 2M+ bindwidth, some may be 512K, and some much less. 700K XAP will take about 10 or more seconds to download before people can run the Silverlight App, It's too long a time.
And I unpack the xap with unzip tool, I found there's about 11 Dlls except the DLL write by me, indlude System.Windows.Controls.dll, System.Windows.Controls.Data.dll, System.Xml.Serialization.dll, etc.
My Question is: Why not pack all the "MOST USED" DLLs into the Silverlight Runtime(Client side), which are install when install the Silverlgith at the first time.
I hope Silverlight 5 will do this, Thanks!
Friday, October 08, 2010 9:42 AM
The number one thing Silverlight has claimed ever since its inception was a small download of the initial install.
So they are unlikey to increase it for a those dlls.
still it would be nice if you used MEF to dynamically pull down dependancys that common dlls would be cached and reused.
Friday, October 08, 2010 3:30 PM
Thanks for raising your concern! metal was actually spot on when he suggested that these assemblies aren't part of the Silverlight runtime because it would increase our install size. However, there's a simple technique you can employ to shrink your download size and make your application start up faster.
In particular, you can follow Tim Heuer's advice in this video on "Loading Dynamic XAPs and Assemblies":
For more general advice on optimizing the startup time of your Silverlight app take a look at my blog post here:
Friday, October 08, 2010 3:45 PM
Most users in the wild out there will encounter Silverlight mostly in the form of a video player, so it's understandable they'd have no use of the 500k DataGrid.
However, extension packages like the Silverlight Toolkit controls could be hosted on Microsoft servers and the Silverlight browser plug-in could be upgraded in the background on-demand once needed.
At least I'd vote for Assembly Caching to work better (i.e. out of browser).
Friday, October 08, 2010 10:34 PM
Thank you for all the replys, which helps me!
And, I insist i's Microsoft's responsibility to manage that DLLs, because they are PART OF THE RUNTIME itself.
Yes, We can get some tips or tricks to reduce the download size of the xap, but If MS can do it, why every one of the developers needs to re-invent again and again.
1) Sweep the DLLs from the SL setup file, so that keep it as small as possible to be easy installed, And, (a) download the dlls on the background after install( just like mepfuso said), or by Windows upgrade, (b) Or, once an application need a 'New' Dlls that is part of the SL Toolkit or is MS published, the runtime shoud download it from MS's server, it's transparent to the software developers, the SL runtime cache the 'New' DLL on the client side for next time use before a new version of that DLL is published.
2) Use one of the other public standard and open source compression algorithoms like bzip2 or 7z to compress the xap, to gain better compress ratio of the xap file.