Loading Assemblies


#1

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


#2

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:

(Disclaimer: haven’t tried this myself yet)


#3

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


#4

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 :frowning:

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.


#5

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.


#6

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


#7

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 :frowning:

Anyone for any ideas on this?

Thanks

Ben


#8

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 :stuck_out_tongue:

Thanks

Ben


#9

The IronPython assembly resolver is in PythonContext.cs. It’s
definitely worth reviewing.