Orion,
Yes, I can use Assembly.LoadFrom to load an assembly from a path (and I am
doing that), but that's not *all* I want to do. I think the easiest way to
communicate my intentions is to ask you the following question:
Q: What happens when I call Kernel.load_assembly in IronRuby, provided I
pass in some assembly name?
A: Modules are created that reflect the types and namespaces within the
assembly (::System::InteropServices, ::System::Reflection::Assembly, etc).
That's the effect I want. If I just use Assembly.LoadFrom, IronRuby will
not treat that the same way as Kernel.load_assembly, nor should it.
Do you see where I'm going with this?
I thought I had found a way to hack around this by getting to the current
context with this little hack:
# ::Object is an instance of RubyClass, which holds a reference to the
RubyContext within which it was created.
# However, IronRuby hides the Context property, so you can't do
Object.context, Kernel.context, etc (which is a good thing).
# But, with a little reflection (and because I know Context really is
there), I can do the following:
context = Object.GetType.get_members.find { |m| m.name == 'Context'
}.get_value(Object, nil)
And then I figured I could do something like this:
context.loader.load_assembly(...)
... but the overload I need is marked private (the one that is public
expects a string containing the assembly's name, as opposed to path). I
suppose I could use reflection again, but it wouldn't work without full
trust. It was a cool idea, nonetheless.
-Charles
On Mon, Aug 9, 2010 at 3:45 PM, Orion Edwards <orion.edwa...@gmail.com>wrote:
> I'm looking through the MSDN docs for assembly loading, and it seems as
> though you can either load an assembly from a path, or from a byte array.
> Both of these methods return an Assembly object.
>
> There doesn't appear to be any other way to actually get an Assembly object
> other than by loading it, as the constructor is protected (assembly is
> abstract), and the only classes that I can see in the framework that derive
> from it are the internal RuntimeAssembly class (which is used for everything
> pretty much), and System.Reflection.Emit.AssemblyBuilder.
>
> As far as I can infer, the only way to actual get an assembly object is to
> load the assembly, so if you're asking how you can load an assembly given an
> Assembly object... it's already loaded.
>
> Am I missing something?
>
>
> On Tue, Aug 10, 2010 at 4:49 AM, Charles Strahan <
> charles.c.stra...@gmail.com> wrote:
>
>>
>> Those are valid points. Perhaps #load_assembly could accept an assembly
>> reference.
>>
>> Sent from my iPhone
>>
>>
>> On Aug 7, 2010, at 5:16 PM, Orion Edwards <orion.edwa...@gmail.com>
>> wrote:
>>
>> What's the advantage to extending require?
>>>
>>> Presumably you're currently using the .NET Assembly.Load or
>>> Assembly.LoadFrom methods to do this? (And if you're compiling code in
>>> memory, you'll certainly be making heavy use of the .NET reflection API's
>>> already anyway)
>>>
>>> Require is a standard part of core ruby, and is meant to take paths.
>>> While it's obvious to overload it to accept paths to dll's as well as rb
>>> files, overloading it to take non-path things (such as .NET assembly
>>> objects) seems like it's diverging a bit too far away from it's normal (ie:
>>> MRI ruby) use, and more into the realms of specific .NET extensions...
>>>
>>>
>>> On 7/08/2010, at 10:08 AM, Charles Strahan wrote:
>>>
>>> What would you all think of having the ability to require a given
>>>> Assembly? I think this could be useful when compiling code in memory, in
>>>> which case there isn't a path to give Kernel.require.
>>>>
>>>> If this is something we could all use, I'll open a ticket for it.
>>>>
>>>> -Charles
>>>> _______________________________________________
>>>> Ironruby-core mailing list
>>>> Ironruby-core@rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>>
>>>
>>> _______________________________________________
>>> Ironruby-core mailing list
>>> Ironruby-core@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>>
>> _______________________________________________
>> Ironruby-core mailing list
>> Ironruby-core@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/ironruby-core
>>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
