Copy local and system dlls' - what is the point?

Question

Visual studio by default copies all dlls' to each project's bin folder. This also includes system dlls' (with the exception of mscorlib.dll and System.dll), such as System.Xml.Linq, System.ComponentModel.Composition (included since SL4) etc.

Since these files are included in each XAP, XAP sizes grow considerably. In my limited testing, setting "Copy local" to false doesn't seem to break anything. Why does Visual Studio add these files to the bin path? Since a user would already have Silverlight, can I assume that these assemblies are already installed in the GAC of each user or am I missing something?

Answer 1

Not By default, dll's that are framework specific that are generally stored in GAC are not copied to output bin directory, and you can assume they will be on the clients machine.

Copy Local on the above mentioned are defaulted to false, so i believe at some stage they were changed to true.

However, without knowing exactly what dll's are referred to i can't say exactly

Answer 2

The files you mention are not included in the runtime install of Silverlight. A Silverlight application that uses these libraries must supply them to the user as part of the download.

You can minimise some of the impact by setting the "Reduce XAP size by using library caching" option in the Silverlight tab of the project properties pages.

This option causes each of these files to be placed in separate Zip files that will be placed in the same folder as the XAP.

This helps in the scenarios where your site may have multiple Xaps for various applications or where you release new versions frequently. For a single app that changes rarely or is hit by many unique visitors its not so helpful.

Answer 3

I think the key here is "doesn't seem to break anything". Because Silverlight apps can be run on many platforms and browsers with varying versions you can't make the assumption something will work because it works on your machine or even one or two others.

If the DLLs are included its because they are potentially needed so you need to be certain they will be there if you are planning on a wide distribution of your app.

For instance, I've been working on a Prism based app with delayed loading of modules. Most of the XAPs have been reduced to around 20k because the secondary modules are guaranteed to be able to use the DLLs they require as they are in the Shell XAP.