The problem :
Our Silverlight RIA Services application isn’t working under “special” circumstances. These special circumstances are : if user launches another instance of Internet Explorer 9 and tries to load page with Silverlight component, app isn’t loaded and after some time IE displaying just white screen (about 1 minute. BTW you could right click on the white surface and see that there si Silverlight loaded) suddenly displays error about RIA service call timeout.
This is the behaviour when deployed to Windows 2008 R2 with IIS 7.5. When launched from development webserver or local IIS 7.5 on my Windows 7 dev box, things worked fine.
First thoughts :
As first thing, I always launch Fiddler as my tool of choice, when it comes to debugging HTTP traffic. What I saw was normal traffic when IE was instantiated once on my localhost.
Under normal traffic you should understand :
- Request to root of the app and IIS returned 401 (please authenticate – see HTTP status codes for reference) (you need to have only windows authentication turned on when using RIA Services),
- Browser repeates the request and but this time with authorization cookie and IIS responded with html, that causes browser to download xap and other files,
- Downloading Silverlight.js file (cached sometimes),
- Downloading our custom SplashScreen.xaml file that is loaded before the whole xap and serves as the name reveales as splash screen of the app,
- Downloading .xap file (the whole app, big zipped file),
- Downloading some resources (images and so on),
- First request to WCF service created by RIA Services and these requests continue as user clicks in the apps and loades requests data (BlablaMainService.svc path requests)
On my machine, traffic looked like this :
Then I browsed to our test server and traffic looked like this :
(please don’t look at the localhost string, I simulated the problem on my machine after we fixed it)
Let me stop here for a moment. At first, I thought that the browser is caching the service requests somehow. They obviously never left the browser. While looking at the Fiddler I realised that there is also other problem.
The solution :
So my first assumption that requests are cached because they never hit the server was wrong. For the first time when the app was fired, IE ignored the SplashScreen.xaml file was missing. Silverlight just displayed normal loading screen and user could continue. Of course, JS error telling that specified .xaml file is missing was there, but you could overlook it. The reason of different behaviour on my Windows 7 dev box and on production Windows 2008 R2 was that the SplashScreen.xaml file’s Build Action in VS 2010 was set to Page and not to Content and thus was not copied to destination dir when deployed. But my local IIS was working on my local copy where this file was present. As always, look at the traffic underneath shiny browser experience, it really matters.