It sounds like a pretty bold statement, but it is true. There is a way to break the built in Silverlight 4 splash screen loader. Most people will probably never see the problem. I only found this bug because the website I am building uses an Akamai caching network that was mis-configured. It was an honest mistake because not everyone is used to using the .xaml mime type yet. IIS 7 works correctly out of the box and shouldn’t have this problem. Anyway, here is what is going on.
Just to make sure everyone is on the same page, here is the setup I will be using. All names have been changed to protect the innocent.
TestApp.html: (this is the page that will host the .xap)
SplashLoader.xaml: this is the loose xaml page that will be loaded as the splash screen<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Name="parentCanvas" Width="Auto" Height="Auto"> <Grid Background="Black"> <Grid HorizontalAlignment="Center" VerticalAlignment="Center" RenderTransformOrigin="0.5,0.5"> <TextBlock x:Name="progressText"></TextBlock> </Grid> </Grid> </Grid>
What is going on?
if you look at the following picture:
In the first pass through (fiddler capture 1), you will see that the application loads both the .xap and the splashloader.xaml. (200 response) Neither are cached. The application loads just fine because the .xaml page has a chance to download an instantiate while the .xap file is still being downloaded. The progress bar updates correctly, and the world is happy.
Where this process breaks down is if you don’t have .xaml files allowed to be cached, but the .xap files are. (fiddler capture 2) You can see that the .xap file is already downloaded and trying to instantiate while the .xaml file still needs time to download. Because the .xap is already loaded and ready to go, there isn’t ever a “download progress” tick, so the splash screen hangs at that point.
To prove that it works with caching, you can use Fiddler’s AutoRespond (or something like it) to reply back with a code 304. the file is loaded locally, and it begins to load again.
Like I said at the beginning of this article, IIS7 works correctly out of the box. If you find yourself in this situation, check your settings, and make sure that the.xaml pages can return a 304. I honestly don’t know if you can even break this in IIS7, but for people using other caching networks, web accelerators, etc…it is entirely possible to miss this setting.
It took me a lot of troubleshooting to figure this one out, so I hope this post helps someone out there save a few hours of mind numbing debugging. We can only hope that this is fixed in SL5.