[IronPython] Re strict imports

Leo Carbajal desleo at gmail.com
Wed Sep 3 03:32:56 CEST 2008

Ok, so I think I misunderstood what a LinkDemand was, as well as the fact
that the exception I'm getting is expected behavior.

I added the [assembly: AllowPartiallyTrustedCallers] attribute to my
assembly and now things work fine outside of the debug environment. From
what I (now) understand, using the LinkDemand attribute is so that the
partially trusted assembly (i.e. the scripts) *can't* access that method.
Does that sound right to you guru types? To test this I imported
System.Windows.Forms and tried to call the MessageBox.Show() method which
failed while running in the domain, as expected. When I removed the
LinkDemand from the ScriptableItem class the calls to it in the script also
worked fine.

So all I have to do is decorate the classes I don't want to be imported from
my assembly into the script with LinkDemands, I think? Is there some way to
reverse that, I.E. some way that I can decorate the classes I want to be
accessible rather than the other way around? I suppose another alternative
is to create the ScriptableItem wrappers in their own assembly and just
reference that, as well as make it callable by partially trusted callers,
while leaving my own assembly alone and thus off-limits to an import.

I will play with it some more, I think. I'm sorry to have wasted some of
your time. =\


On Tue, Sep 2, 2008 at 7:38 PM, Leo Carbajal <desleo at gmail.com> wrote:

> This is a condensed version. You'll have to sign the assembly or you'll get
> an error at the domain creation step, other than that this should run just
> by starting a new console application, adding the IPY and DLR DLLs, and then
> copying and pasting this file over the default generated code.
> Even after starting a new project to make sure my sample builds I still
> observe the same behavior.
> ---
> LC
> On Tue, Sep 2, 2008 at 6:36 PM, Curt Hagenlocher <curt at hagenlocher.org>wrote:
>> Do you have a simple reproduction that doesn't include any of your
>> domain-specific code?
>> On Tue, Sep 2, 2008 at 4:30 PM, Leo Carbajal <desleo at gmail.com> wrote:
>>> So here's a strange wrinkle,
>>> when I run this with the debugger (unmodified except for adding the
>>> IronPython assemblies as full-trust on the domain) it works fine and as
>>> expected. If I run it without the debugger attached it gives me the same
>>> exception as before, when I catch the exception myself I also get this
>>> tidbit:
>>> The assembly or AppDomain that failed was:
>>> Microsoft.Scripting, Version=, Culture=neutral,
>>> PublicKeyToken=31bf3856ad364e35
>>> The Zone of the assembly that failed was:
>>> MyComputer
>>> The Url of the assembly that failed was:
>>> file:///B:/Code/IronPythonShell/IronPythonShell/bin/Debug/Microsoft.Scripting.DLL
>>> If I build and compile the code as Release instead of Debug I get:
>>> System.Runtime.Serialization.SerializationException: Type
>>> 'System.Scripting.SourceUnit' in assembly 'Microsoft.Scripting.Core,
>>> Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is not
>>> marked as serializable.
>>>    at Microsoft.Scripting.Hosting.ScriptRuntime.ExecuteFile(String path)
>>>    at IronPythonShell.Program.Main(String[] args) in
>>> B:\Code\IronPythonShell\IronPythonShell\Program.cs:line 54
>>> It's a little beyond odd to me, but like I said before I fear I don't
>>> fully understand what's going on behind the goo. The only consolation is
>>> that I can at least built out my scripting system in working form and later
>>> run it under a more trusted domain for production by simply removing the
>>> domain from the Runtime.Create() constructor and then adding it later. (At
>>> least, I hope this is the case)
>>> ---
>>> Leo C.
>>> On Tue, Sep 2, 2008 at 4:50 PM, Shri Borde <Shri.Borde at microsoft.com>wrote:
>>>>  The CLR doesn't dump out full exception information on
>>>> SecurityExceptions in partial trust – you can get a lot more information if
>>>> you look at the exception in a debugger, or if you Assert for FullTrust
>>>> before doing a ToString on the permission.  Once you do that, you should be
>>>> able to get more data including the demanded permission and the assembly
>>>> which caused the demand to fail, instead of the message saying "The
>>>> granted set of the failing assembly was:" which does not say which
>>>> assembly is causing the problem.
>>>> Also, can you try adding IronPython.dll and IronPython.Modules.dll to
>>>> the fullTrustAssemblies argument to AppDomain.CreateDomain<http://msdn.microsoft.com/en-us/library/ms130766.aspx>
>>>> ?
>>>> Thanks,
>>>> Shri
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080902/0efffa5b/attachment.html>

More information about the Ironpython-users mailing list