Probably all of us have identified at some point the following trend in software development — newer version usually means bigger assemblies. Sure, some of the new stuff is features that we use on a daily basis; but some of the new stuff is just eye candy that we don't always use.
In fact, wouldn't it be nice if we could get just the software with the default looks; get the job done then and, if needed, add that sweet UI candy to it later?
And in order to tackle this problem — maintain a reasonable file size of the main Telerik AJAX assembly (Telerik.Web.UI.dll) while having pluggable eye candy — we've decided to introduce a separate assembly just for Rad AJAX Controls skins, namely the Telerik.Web.UI.Skins.dll.
We first shipped the assembly as a part of the official Q2 2011 release and some of you may have already noticed it. It contained just the four new skins added with Q2 2011 — Transparent, Office2010Black, Office2010Blue and Office2010Silver.
As of Q3 2011, all existing skins, except Default, are moved to the skins assembly. By doing so, we were able to shave few megs off the main assembly and transfer that load to the skins assembly (see screenshot below). And though 6 megs might seem modest for some, it's some 40% reduction in terms of the file size.
In addition, we'll put all new skins in the skins assembly, keeping the main assembly trim.
If you need to use any of embedded skins other than the Default one, all you need to do is add a valid reference to the new skins assembly in your project. You won't need to register this additional dll explicitly on your pages. Instead, simply copy it and reference it either from the /bin folder of your project (see the screenshot below) or the Global Assembly Cache (GAC).
Note: if you don't intend to use a skin other than Default or you have your own custom skins, you do not need to copy and reference the skins assembly at all. By not copying / referencing the skins assembly, only the main assembly will be loaded in the memory, thus achieving some memory optimization gains.
We know there is room for more improvements in that area — like reusing more of the resources, trimming down script and style files ... and why not having a way to build and deploy just the skin / skins you need. We know it and we'll get there. But to get there, we needed to make this seemingly small, yet important first step — introduce a separate skin assembly.