[IronPython] Loading IronPython.dll from memory
fuzzyman at voidspace.org.uk
Wed Dec 17 22:37:37 CET 2008
Jeff Slutter wrote:
> [I can work around this, but I'm curious if there is a solution]
> Due to some crazy requirements, I'm trying to load my assemblies from
> memory. I have setup an Assembly Resolver with:
> AppDomain.CurrentDomain.AssemblyResolve += new
> And it gets called. Inside the ResolveInternalAssembly I do the following:
> 1) check my Dictionary to see if I have already loaded the assembly, if
> so I return it, otherwise...
> 2) I, currently, open the file, read in the file to byte and then call
> 3) AppDomain.CurrentDomain.Load(asmbytes) to load the Assembly, store it
> to the dictionary and return it.
> (see: http://weblogs.asp.net/justin_rogers/archive/2004/06/07/149964.aspx)
> This works well and all until I get to the following code within one of
> my loaded assemblies:
> m_engine = m_runtime.GetEngine("Python");
Is this using the IronPython hosting API? That doesn't look like code
that would have worked with any recent version of IronPython.
engine = Python.CreateEngine();
> It throws an exception saying:
> Type 'IronPython.Runtime.PythonContext' doesn't provide a suitable
> public constructor or its implementation is faulty: The type initializer
> for 'IronPython.Runtime.SysModule' threw an exception.
> I assume this is some sort of security/permissions problem because that
> is the main thing that is different when loading an assembly from memory
> than file.
> My work around is to pre-load the IronPython.dll assembly before hooking
> up my AssemblyResolve (its the only one I have to 'preload')
> dynamicAssemblyHash["IronPython"] =
> Any ideas?
> Users mailing list
> Users at lists.ironpython.com
More information about the Ironpython-users