At the end of the day on Saturday's Silverlight Dev Camp, I gave an ad-hoc talk on controls and silverlight. The conversation quickly turned to a lot of Q&A on how the Silverlight control and content is loaded. I covered that there, but for those who didn't attend, this is useful information.
When file requests are made to the server, they currently follow normal browser caching and access rules. Silverlight makes the request through the browser stack. Currently the DLLs are set to expire 29 hours from the request. As with any browser-based application, caching can get you in trouble when you are doing a lot of debugging. During my own tests here, I kept switching page.xaml back and forth between a version with the x:Class removed and one with it intact. I had to clear the browser cache in between changes in order to get back reliable results. Also note that if your files (including DLLs) on the server have not been changed and they care cached locally, you'll get back a 304 not-modified and the file will not be brought back down to the browser.
One key point that I spoke about and my testing proved out is that the only thing that decides whether or not your application is a CLR application or a JavaScript application, is the inclusion of x:Class in your main xaml file. The version number you put in createSilverlight is there only to check to make sure the user has a minimum version and redirect them to the correct download location otherwise. For example, I put "1.0" in the version parameter, and ran my Managed Silverlight application just fine because I had 1.1 already installed. This points to the fact that you will always need to test your Silverlight apps on a virgin machine to make sure that all the moving pieces are correctly configured. Just because it works on a machine that already has Silverlight installed does not imply that it works correctly on one without.
(The other thing this points to is a problem in public naming for Silverlight. Rather than 1.0 and 1.1 we should refer to them as Unmanaged and Managed Silverlight, or something along those lines, especially since 1.1 is backwards compatible with unmanaged Silverlight code "1.0".)
The DLLs are downloaded once your main xaml file is loaded (not in the "loaded event sense" but in the "file is loaded into memory" sense) and parsed. Silverlight decides on what DLLs to download by using the x:Class and the manifest in the DLLs, following normal .NET rules.
When attempting to resolve DLL locations, Silverlight will first check in the location of the main DLL (typically ClientBin) and then it will check in the location of the Page.xaml file (typically one level up). When downloaded, all these files end up in your temporary internet files folder. Clearing your cache in IE or FireFox is sufficient to remove the application from your local PC.
Each running instance of Silverlight, in the current 1.1 alpha, gets its own copy of the CLR and its own app domain. If you have five instances of Silverlight on your page, you get five CLRs. This isn't great for memory usage or performance, of course. I understand Microsoft is considering letting all instances within a browser app share an app domain in a future version. No public announcements have been made yet on that topic. In the mean time, try and keep your Managed Silverlight applications to one instance per page.
[ To test everything, I relied on Fiddler, Visual Studio 2008 Beta 2, and Silveright 1.1 alpha - September Refresh using IE7 and Windows XP SP2. In other configurations, your results may vary. Comments welcome. ]
