… and then there is that project where the XAP for a Silverlight application is dynamically created on the server. There are some good reasons for that: an ASP.NET HttpHandler lets you implement additional authorization logic, or you might want to inject generated XAML resources into the XAP file (remember, it’s just a zip file with a different extension, so it’s fairly easy to deal with it). But that’s another story.
So in that project, an ASP.NET HttpHandler is used to serve the XAP. By general practice, HttpHandlers are invoked by a URL with the file extension ashx; and because we like sticking to standards, it is done this way. The HTML page that hosts the Silverlight application is modified to reference the HttpHandler (see below), and behold: the solution works like a charm.
<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" > <param name="source" value="DynamicXap.ashx"/> <!-- other parameters omitted for brevity --> </object>
Well, almost. No one was really missing it that much, but the loading screen of the Silverlight application was gone. This animation is built into the Silverlight plug-in so it can be displayed before the XAP container is loaded (and you can provide your own custom one as well) And especially when you’re on a slower network, it’s helpful to have an indicator that something is happening rather than just a white slate of blank pixels.
My first thought was that the handler was not passing the right HTTP headers (it was) or that it would write the whole content in one chunk, and the Silverlight plugin would start showing the animation only after some bytes have been sent (but the handler does write the headers first, and uses a chunked transfer).
So I switched from looking for the obvious to collecting empirical evidence: where is the difference between returned the static XAP file and the HttpHandler? Fiddler AutoResponder is an excellent tool for this kind of exercise: It can replace the server’s response for a request with content that you can directly control. So I captured the response from getting a static XAP file, with headers, content, everything. I was still thinking it was something with the HTTP headers, so I started removing them one by one, but to no avail: the animation was stubbornly still showing – so this way not a header issue.
Then I modified the AutoResponder to return the captured output for the static XAP for the URL of the HttpHandler so that the _very_same_response_ was given. The animation is shown when the Url ends with “.xap”, but not with “.ashx”.
And that turned out to be the solution: the animation only shows up when the downloaded XAP container has a URL that ends with “xap”. Mapping the HttpHandler to handle requests that end with “xap” and not “ashx” finally solved the problem.