I snipped a little extra - my code is really:
Dictionarystring, object runtimeOptions = new Dictionarystring,
object();
runtimeOptions[Debug] = true;
m_runtime = IronPython.Hosting.Python.CreateRuntime(runtimeOptions);
m_runtime.LoadAssembly(typeof(String).Assembly); // Add reference to System
m_runtime.LoadAssembly(typeof(Uri).Assembly); // Add reference to mscorlib
m_runtime.LoadAssembly(System.Reflection.Assembly.GetCallingAssembly());
m_engine = m_runtime.GetEngine(Python);
I've also tried replacing the above with:
m_engine = Python.CreateEngine();
and I get the same exception in the call to Python.CreateEngine()
(Note: the exception exists without all the extra LoadAssemblys and
stripped to the bone).
Michael Foord wrote:
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
ResolveEventHandler(ResolveInternalAssembly);
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.
Try:
engine = Python.CreateEngine();
Michael
It throws an exception saying:
Microsoft.Scripting.InvalidImplementationException
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] =
Assembly.LoadFile(System.IO.Path.Combine(assemblyLocation,
IronPython.dll));
Any ideas?
-Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
