Silverlight Out-Of-Browser Woes

I have a Silverlight Line Of Business application which is run on an intranet as an Out Of Browser app.
Nothing unusual.

Now since we have a staging server for testing releases we rewrite the manifest file inside the Xap file so that the application name is concatenated with the instance name. This appears in the window title-bar and means I can have the production and test versions installed on the desktop and easily tell them apart. Reduces the chance of doing something dumb to the production system by mistake…
Very handy and pretty unusual.

The Silverlight client also makes use of the Microsoft Enterprise Library which gets configuration information from a specially crafted xaml file – also located in the Xap. This xaml file is dynamically generated from a conventional configuration file on the server. This means that changes to the config on the server will cause a new Xap to be generated and the app will detect this upon start-up.
I reckon this is very rare.

All this is preamble – the problems started when the client needed elevated permissions – this broke auto-update because the Xap wasn’t signed and it couldn’t be signed during development because it is rewritten by the web-server…

So now the web-server signs the Xap package after rewriting has been completed – with a certificate issued by the local domain controller (this neatly avoids certificate trust problems as client machines already trust the issuer.)

I don’t know about you but this might make for a few sleepless nights…
Still having a working auto-update is nice!

I had quite a few hoops to jump through to get the code-signing certificate for the server too but that is another story – this blog post is long enough as it is!


Silverlight Surprise

Just fixed an interesting little bug discovered late in pre-rollout testing.

Seems when your Silverlight application is installed in Out Of Browser mode you have to explicitly setup the culture for the UI thread – if you want something other than the default assigned to new OOB sessions.

Since I use the English language version of Windows and Silverlight the default culture is en-US even though my application installs while running under en-GB.

The answer was simple – when running in browser save the thread culture to local storage and when running out of browser set the thread culture explicitly from the saved state.

Incidentally this bug is only noticeable if you have XAML bindings that use binding converters or perhaps the StringFormat binding attribute.

In my program it showed itself in some dates shown on the UI where I use a custom converter to show UTC dates in local time.

Hope this helps somebody else – happy coding!