views:

162

answers:

3

Hi... I don't know if anyone can advise about this one. We have written and implemented a LOB Silverlight 3 application - which we are currently testing at a clients site.

We have come across the problem, where on a few of the machines on site the browsers crash randomly. The machines run Windows XP SP3 - the browser is Firefox.

We suspect that it may be because these machines browser's seems to be unreliable as they had some plugins installed etc. and a suggested solution was to implement the application in the out of browser mode.

What I want to know is, when a Silverlight 3 Application is running out of browser, is it still relying on a specific browser in the background... or would this solve our problem if the browser is "unstable" because of plugins?

+3  A: 

I'm struggling for evidence but I'm pretty sure I remember reading that out-of-browser uses the Internet Explorer engine.

EDIT

This post reinforces my memory.

And this article implies the same, if you go to the section "Detecting Network Connectivity and Out-of-Browser Status" and read the final para, beginning "You can use local messaging to communicate between...".

serialhobbyist
AnthonyWJones is right, IE has nothing todo with silverlight when running OOB, you'll even notice that the HTMLPage object is partially inaccessible when running OOB
Neil
+2  A: 

No. There is no connection between a Silverlight OOB application and the browser in which it was running when installed. Once running as an OOB application Silverlight uses its own ClientHTTP stack and no longer depends on the Browser HTTP stack.

Assuming the instability is a result of Firefox extensions then running the app in OOB may help. Bear in mind though, that the browser's HTTP stack is likely to be more efficient and you loose automatic cookie handling.

AnthonyWJones
Thanks for the feedback. Appreciate it
Mark Pearl
A: 

If silverlight is crashing within the browser then there's only a few parts of silverlight that actually rely on the browser operating correctly, such as calls to webservices must go through the browsers HTTP facade, maybe too many responses from the server are queued due to a lagging UI which results in a crash since too many responses are trying to fire events for UI changes at once, unlikely yes i know, but its an idea.

Lifetime management is also handled by the browser, a plugin may be trying to recycle the silverlight process and restart it.

Try using this debugging utility, silverlight spy to get to the bottom of the problem

Neil