Silverlight out of sandbox?

Question

I'd like to use Silverlight's CLR instead of .NET CLR. For these reasons, at least:

1. Cross-platform ability
2. I need to avoid any compatibility problems for my .NET-written plugin. Process can host only sole .NET CLR, and when several plugins targeted for different CLR versions are in the same process - it becomes a great pain. Silverlight CLR's doesn't have such limitation.
3. Silverlight supports mini-deployment (only CLR core and necessary assemblies)

The trouble is that Silverlight CLR is always sandboxed. Is there any way to get Silverlight app out of sandbox?

Silverlight class library contains some methods that can't be called from sandboxed app - thus, I assume there is some way to get app unsandboxed? Or they just forgot to remove these methods, when were porting class library from .NET?

UPD: got an idea. At least, Silverlight class library assemblies can call any (unsafe) code. Is there any way to pretend my assembly is a part of class library?

Answer 1

No, there isn't.

Answer 2

I don't believe there is a way to have the silverlight runtime operate outside of the security 'sandbox'.

As a consolation, you can create silverlight applications that run outside of the browser, so at least they feel like they're desktop applications.

If this helps you can learn more here:

http://wildermuth.com/2009/03/18/Enabling_Out-of-Browser_Support_in_Silverlight_3

http://timheuer.com/blog/archive/2009/03/18/silverlight-3-offline-update-framework.aspx

http://videos.visitmix.com/MIX09/T45F

Update: here's a video on the official Microsoft Silverlight website

http://silverlight.net/learn/learnvideo.aspx?video=187318

There's actually lots of great tutorials etc. on silverlight.net

Other than that I recommend following Tim Heuer and Scott Gu for official Silverlight annoucements.

Answer 3

We did consider such project by using Mozilla's XUL Runner to be a browser container that can host silverlight and XUL has lots of apis which can be available to browser and its silverlight code if its executed with enough privileges. Its little trick to make a javascript bridge between the apis of XUL and browser host to provide all apis not available to silverlight.

We stalled the project because Microsoft didnt support silverlight truely for other platforms and since currently Microsoft only provides silverlight for windows and mac intel based only, that is practically not useful to go truely system independent at all. Its really not Microsoft's intension to make it truely system independent, so we went on using Adobe AIR.

But you can try hosting silverlight in XUL and that way XUL is available to all platforms and tomorrow when mono becomes stable, you can certainly use it as good platform. But the speed is terribly slow. And there are real bad threading issues as well.