Hello, Just been playing around with some interop with our SDK. This is our setup. SDK is installed into C:\Program Files\SDK\ ir is C:\IronRuby\ir.exe I then add C:\IronRuby to my path folder. I attempt to do the following to access the SDK. require 'C:\Program Files\SDK\a.dll' require 'C:\Program Files\SDK\b.dll' require 'C:\Program Files\SDK\c.dll' B has a dependency on a. a loads file, but when loading b.dll an exception is thrown within LoadTypesFromAssembly because it cannot find a.dll. This is a serious problem, without copying all the assemblies into my IronRuby directory I'm not sure how to load the types and use our SDK? Installing into the GAC isn't an option. Please help! Thanks Ben
on 2008-12-09 20:15
on 2008-12-09 20:23
Few things in CLRland are more frustrating than the Fusion loader. Your simplest short-term fix is probably to set the probe path in ir.exe.config: <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <!-- Indicates where the runtime should search for other assemblies. --> <probing privatePath="C:\Program Files\SDK" /> </assemblyBinding> </runtime> </configuration> (Disclaimer: haven't tried this myself yet)
on 2008-12-09 22:59
> require 'C:\Program Files\SDK\a.dll' > require 'C:\Program Files\SDK\b.dll' > require 'C:\Program Files\SDK\c.dll' Never tried that with IronRuby, but would the following work ? $LOAD_PATH << 'C:\Program Files\SDK\' -- Thibaut
on 2008-12-09 23:48
No. You need to set it in App.config. But I think the probe path could only be a subdirectory of the app. That means a subdirectory of a path where ir.exe is. We are working on improving assembly loading for IronRuby. Tomas
on 2008-12-10 11:15
Thanks for the responses. Tomas is right, the appdomain didn't work (plus, it feels as dirty as copying all the assemblies). I wanted to hook into the AssemblyResolve event on the AppDomain, however it appears as if I don't have access to the appdomain! When I try System::AppDomain::CurrentDomain.methods, I get a NameError again. Disappointing :( I'll see if I can come up with some hacky way, its a shame that I can't manualy load in all the assemblies and you attempt to load them from the AppDomain first (then I would have a require 'sdk.rb' file with all the dependencies loaded in order) Thanks Ben On Tue, Dec 9, 2008 at 9:46 PM, Tomas M.
on 2008-12-10 17:32
CurrentDomain is a static method, not a class -- so you want System::AppDomain.current_domain The AssemblyResolve event comes with its own set of odd side effects that may bite, but it is how IronPython deals with the issue.
on 2009-01-05 12:59
I'm back in the office so decided to give this another go. The problem is, it appears to keep attempting to load a particular assembly, resulting in a stackoverflowexception. The method Assembly.load_from(path) never appears to return. I've tried to put a (if already saw then don't load) but I get an error "Expected System.Reflection.Assembly, got System.Dynamic.Null" This is because i do return nil, but i'm sure that's what I did in C#. This works in IronPython, but I can't find the code where its implemented within the codebase :( Anyone for any ideas on this? Thanks Ben
on 2009-01-05 23:23
The IronPython assembly resolver is in PythonContext.cs. It's definitely worth reviewing.
on 2009-01-12 13:31
Hi Curt, I finally got this working. Sadly, looking into the AssemblyResolve event within IronRuby always caused a stackoverflow, certain assemblies would keep attempting to load themselves. I was using AssemblyResolve and Assembly.LoadFrom and LoadPath, but nothing helped. Last night, I looked into the AssemblyResolve event from within RubyContext and everything works just as expected. No errors, no stack overflows. I then used the GetSearchPaths() methods as possible locations to load assemblies from, this means I can add paths from IronRuby to use when loading assemblies via the $: variable. Appears to work well - bit annoying I can't submit the patch :P Thanks Ben