Dino Viehland wrote:
Here's a working example (no partial trust) in Python:
Cool! Thanks Dino. I don't normally speak to you here. :-)
Michael
import clr
clr.AddReference('Microsoft.Scripting.Core')
import System
from Microsoft.Scripting import SourceCodeKind
from Microsoft.Scripting.Hosting import ScriptRuntime
ad = System.AppDomain.CreateDomain('foo')
sr = ScriptRuntime.Create(ad)
sr.LoadAssembly(clr.GetClrType(str).Assembly)
py = sr.GetEngine('py')
su = py.CreateScriptSourceFromString('import System\nprint
System.AppDomain.CurrentDomain\n', SourceCodeKind.File)
su.Execute()
Indeed partial trust might be a problem - we've run into a few bugs there on the desktop
CLR where we have divergent code paths from Silverlight. It's also only available on
Orcas / .NET 2.0 Sp1 or later where we'll use anonymously hosted dynamic methods if
they're available. Finally I believe our "optimized module" and other
subclassing of .NET standard types won't work because those need full reflection.emit but
I haven't verified that.
Anyway, the issue of partial trust has been brought up with various people on
the DLR side of things and there should be a push at some point to ensure this
works.
But there are other advantages w/ app domains than just security. You also get:
the ability to unload code w/ a decreased worry of corruption
This is using Thread.Abort safely. Large amounts of code can
be safely unloaded because there's no shared state outside of the app domain
which can be corrupted (note there's some code in the world that this doesn't
apply to, but it applies to most of the .NET framework).
isolation of static variables that live outside of the script
environment
I think Tomas alluded to this
the ability to unload assemblies
Ye-olde-reason to use app domains on the CLR
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Monday, April 28, 2008 4:20 PM
To: [email protected]
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog
Tomas Matousek wrote:
[snip...]
And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
Does this actually work? No one has been able to post working code on
creating an IronPython engine in another app domain on the IronPython
mailing list.
Can you use this to place restrictions on the app domain - like restrict
which assemblies can be loaded and control network / filesystem access?
A working example would be a wonderful thing...
The reason I am dubious is that it seems that the code generation used
by the DLR requires pretty much full trust in .NET 2, so *any*
restrictions (which is usually the point of running in another app
domain) blow up. I would dearly love to be proved wrong on this of course.
Michael Foord
That was easy, wasn't it?
Tomas
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lam
(IRONRUBY)
Sent: Monday, April 28, 2008 7:05 AM
To: [email protected]
Subject: Re: [Ironruby-core] Regarding IronRuby... How true it sounds from this
blog
Sanghyeon Seo:
It seems to be a rather good overview of the status to me. I mostly
agree, except for the accusation that "Microsoft would never back an
OSS web framework like Rails in preference to its own".
He also gets a number of important technical details wrong about IronRuby, I'll
respond later today.
Thanks,
-John
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
