Welcome to Pete Brown's 10rem.net

First time here? If you are a developer or are interested in Microsoft tools and technology, please consider subscribing to the latest posts.

You may also be interested in my blog archives, the articles section, or some of my lab projects such as the C64 emulator written in Silverlight.

(hide this)

How Silverlight is Loaded and Instantiated

Pete Brown - 07 November 2007

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. ]

posted by Pete Brown on Wednesday, November 7, 2007
filed under:      

10 comments for “How Silverlight is Loaded and Instantiated”

  1. Ashish Shettysays:
    You describe the flow pretty well. Silverlight relies on the browser stack for downloads and therefore cache control policies and user preferences etc. apply. There's no enforcement in our code of a 29hr wait.

    You final statements are not accurate though. There's one instance of CLR per host (browser) process, but you rightly state that there's 1 AppDomain per instance of Silverlight plug-in. The infrastucture overhead from multiple Silverlight instances on a page is fairly low. Are there specific perf issues you've encountered?

    The idea of sharing AppDomains among multiple SL instances on a page is interesting and indeed something we've dabbled with. I personally haven't seen scenarios that justify the cost and security risks. Are there great scenarios that you think would open up with that feature?
  2. Pete Brownsays:
    Hi Ashish

    Thanks for the info and the correction on the instance issue.

    The 1 CLR instance per app was based on that same comment and recommendation made by some MSFT folks at MIX and then (as I recall) on Silverlight.net. I'm glad to hear that there's only one CLR instance per Silverlight control. THe only perf issues I ran into were early on, and perhaps have been resolved. I had multiple silverlight controls on a page, running animations (like my balloons sample) and a simple button sample. CPU was getting pretty bogged at the time with even one Silverlight instance, so that test likely doesn't apply any more.

    The main instance where I've been asked about multiple instances per page is when doing silverlight-based webparts in MOSS. Discrete silverlight-based menus and/or chrome and then any number of silverlight-based web parts that show, for example, video, charts, KPIs, etc. On a typical MOSS portal page, when Silverlight is used, you can probably expect to see 3-5 instances.

    I also appreciate the validation of the flow. I got this just by testing the 1.1 alpha from the outside, so I'm glad I got some of it correct :)

  3. Poonamsays:
    I tried out a sample in Silverlight 1.1. It uses C# code behind for handling events. Code compiles just perfect in Orcas Beta2 studio.

    However, when I execute the code in IE 6.0, it does not show me any results :(
    I have silverlight 1.1 framework installed on my machine. However, I get a blank screen and Page_Load method never gets triggered.

    Could you please suggest what could be missing in this?
  4. Pete Brownsays:
    Hi Poonam

    Often times that means you have an error in your xaml itself. Strip the xaml down to just the very basics and see if you can get it to come up. XAML parsing errors can be tricky to catch.

    If that isn't it, please post your question on the silverlight.net "Programming with .NET" forum here:


    I'll be able to better help you there. When you post, please post the important bits of code/xaml that you use.

  5. Pete Brownsays:
    @Ray yes, there are a number of changes. Please see my two-part article from March 2008


    Also, to answer the question you posted on my beta site regarding the chat app code, please see the two-part Silverlight Chat application article I posted this month. (You didn't leave an email address there and don't have one on your site)

    Hope that helps!


Comment on this Post

Remember me

6 trackbacks for “How Silverlight is Loaded and Instantiated”

  1. Christopher Steensays:
    ASP.NET BBCode extension for BlogEngine.NET 1.2 [Via: Mads Kristensen ] Dynamically Render A Web User...
  2. WynApsesays:
    Silverlight Cream for November 8, 2007 -- #120
  3. POKE 53280,0: Pete Brown's Blogsays:
    In a break from some of my previous Silverlight talks, today at the NoVA Code Camp, I did a mostly slideless