[rdnzl-devel] loading an assembly in clisp 2.42
I have a library written in C# -- Foo.dll. I am able to load rdnzl in clisp, and run simple examples that involve importing registered libs: "Hello World!", etc. No matter where I put Foo.dll, (load-assembly "Foo") results in: WARNING: Returning NULL object from .NET call NIL When I specify a full path: (load-assembly "c:\\Documents and Settings\\user\\Desktop\\Foo.dll") I get: *** - .NET error (System.IO.FileLoadException): The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047) I'm not sure what to do at this point. I am using rdnzl-0.11.0 with the included dll and Foo is compiled in Visual Studio 2005. I also get the same result using a patched rdnzl-0.5.0 compiled in Visual Studio 2008. Any Ideas? Thanks, Matt
On Sat, 20 Oct 2007 05:05:05 +0000 (UTC), Matthew Swank <akopa.gmane.poster@gmail.com> wrote:
I have a library written in C# -- Foo.dll. I am able to load rdnzl in clisp, and run simple examples that involve importing registered libs: "Hello World!", etc. No matter where I put Foo.dll, (load-assembly "Foo") results in:
WARNING: Returning NULL object from .NET call NIL
You should succeed if you put Foo.dll in the folder where your CLISP executable is (/before/ you start CLISP).
When I specify a full path: (load-assembly "c:\\Documents and Settings\\user\\Desktop\\Foo.dll")
I get:
*** - .NET error (System.IO.FileLoadException): The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
LOAD-ASSEMBLY uses System.Reflection.Assembly::LoadWithPartialName internally - that one doesn't work with full pathnames.
I'm not sure what to do at this point.
(rdnzl:invoke "System.Reflection.Assembly" "LoadFrom" "c:\\Documents and Settings\\user\\Desktop\\Foo.dll") should give you the assembly. HTH, Edi. PS: See the notes in the documentation about CLISP. You should try one of the Lisps that are fully supported instead.
On Sat, 20 Oct 2007 16:54:55 +0200, Edi Weitz wrote:
On Sat, 20 Oct 2007 05:05:05 +0000 (UTC), Matthew Swank <akopa.gmane.poster@gmail.com> wrote:
I have a library written in C# -- Foo.dll. I am able to load rdnzl in clisp, and run simple examples that involve importing registered libs: "Hello World!", etc. No matter where I put Foo.dll, (load-assembly "Foo") results in:
WARNING: Returning NULL object from .NET call NIL
You should succeed if you put Foo.dll in the folder where your CLISP executable is (/before/ you start CLISP).
When I specify a full path: (load-assembly "c:\\Documents and Settings\\user\\Desktop\\Foo.dll")
I get:
*** - .NET error (System.IO.FileLoadException): The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)
LOAD-ASSEMBLY uses System.Reflection.Assembly::LoadWithPartialName internally - that one doesn't work with full pathnames.
I'm not sure what to do at this point.
(rdnzl:invoke "System.Reflection.Assembly" "LoadFrom" "c:\\Documents and Settings\\user\\Desktop\\Foo.dll")
should give you the assembly.
HTH, Edi.
Thanks, all those suggestions worked.
PS: See the notes in the documentation about CLISP. You should try one of the Lisps that are fully supported instead.
Well, I am constrained to use clisp or sbcl. I plan on getting around the callback issue by running the gui in a separtate .NET thread and running and event loop on the lisp side to listen to .NET events over a set of synchronized channels. Btw, it needs a little cleanup, but I've updated the VS 2005 version of the cpp project to conform to the 0.6.0 protocol. Would you like a copy of it when I have it ready? Matt -- "You do not really understand something unless you can explain it to your grandmother." — Albert Einstein.
On Sat, 20 Oct 2007 18:54:48 -0500, Matthew D Swank <akopa.gmane.poster@gmail.com> wrote:
Btw, it needs a little cleanup, but I've updated the VS 2005 version of the cpp project to conform to the 0.6.0 protocol. Would you like a copy of it when I have it ready?
Yes, please. Thanks.
(rdnzl:invoke "System.Reflection.Assembly" "LoadFrom" "c:\\Documents and Settings\\user\\Desktop\\Foo.dll") should give you the assembly.
A thing that might be of interest here is that assemblies loaded in a LoadFrom context don't work exactly like assemblies loaded with Load/LoadWithPartialName and so forth; for example de-serialization always uses Load so that won't work; and there are other diverse issues. See http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx . A fix that works is subscribing to the AppDomain.AssemblyResolve event, which is triggered when Load/LoadWithPartialName fails; you can add your own code there to find the assembly any way you need to. I haven't been able to actually do this in lisp (ACL7) via RDNZL though, as somehow I get a crash when the new assembly is returned to the AppDomain triggering the event. But subscribing to the event in C# code used by RDNZL works fine; I've attached an example class that can do this. With this class loaded (also with LoadFrom) using Load and LoadWithPartial will work with any other paths you specify. I think one is probably not supposed to do this either, but it does work and people do use it. (I've also attached the non-working lisp that should have handled the event in case anyone is interested.) Iver Odin Kvello iok@selvaag.no
participants (4)
-
Edi Weitz -
Iver Odin Kvello -
Matthew D Swank -
Matthew Swank