Forum: IronRuby IronRuby not loading DLL

I have been using IronRuby for a while now to do simple scripting
against DotNet DLLs with great success. I ran in to a problem recently
where I am asking IronRuby 1.1.1 to require a DLL but it does not appear
to be loaded. I do not get an error message but cannot instantiate any
types from the DLL. If I do "p Object.constants" it does not return any
namespaces or classes from the DLL.

When trying to do:
"mdMATCHUPOBJECTLib::mdMUIncrementalClass.new"

I get the error:
"undefined method mdMATCHUPOBJECTLib"

Where mdMUIncrementalClass is a class in the DLL and mdMATCHUPOBJECTLib
is the namespace. This works perfectly in C#/VisualStudio with the same
DLL (I am basically using the exact same code in C# and Ruby). If it
helps, this is an Interop DLL created by Visual Studio from a COM DLL.

I may be totally "off base," but have you tried using the fusion viewer
to ensure that you do not have a problem with .NET loading the DLL (and
its underlying COM object).

---
Larry Jones
||| Senior Level Development Engineer
Aspen Technology, Inc. ||| +1 281-504-3324 ||| fax: 281-584-1062 |||
www.aspentech.com

You need to use const_get to access classes/namespaces whose names are 
not compatible with Ruby naming conventions.
A module in Ruby must start with capital ASCII letter.

const_get(:mdMATCHUPOBJECTLib).const_get(:mdMUIncrementalClass).new 
should work.

Tomas

Tomas, how would you feel about adding an optional block param to
require/load_assembly for overriding how .NET types are mapped to 
constants?
 That might be prove beneficial in cases such as these.

-Charles

On Fri, Mar 25, 2011 at 5:37 PM, Tomas Matousek <

What would such block usually do? Uppercase the first letter of a 
lower-cased class/namespace? We could do that or some other mangling 
automatically. Is there any value in customizing the mangling?

Being it automatic would help you to discover the constants since they 
would appear in Module#constants.

Tomas

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Charles 
Strahan
Sent: Saturday, March 26, 2011 10:00 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby not loading DLL

Tomas, how would you feel about adding an optional block param to 
require/load_assembly for overriding how .NET types are mapped to 
constants?  That might be prove beneficial in cases such as these.

-Charles

On Fri, Mar 25, 2011 at 5:37 PM, Tomas Matousek 
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>> 
wrote:
You need to use const_get to access classes/namespaces whose names are 
not compatible with Ruby naming conventions.
A module in Ruby must start with capital ASCII letter.

const_get(:mdMATCHUPOBJECTLib).const_get(:mdMUIncrementalClass).new 
should work.

Tomas

I figured that it's always nice to have options - especially if there 
are
conflicts.  Capitalizing the first letter would probably work in 99% of
cases, but I could imagine there *might* be case where you have an xFoo 
type
and an XFoo type in the same namespace.

That's probably being pedantic though - just capitalizing the first 
letter
sounds like a pragmatic solution to me.

-Charles

On Sat, Mar 26, 2011 at 10:01 PM, Tomas Matousek <

You can always use const_get for the 1% cases. IMO, having 
non-capitalized namespaces and classes is already 1% case, since such 
libraries violate .NET design guidelines.

Tomas

From: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Charles 
Strahan
Sent: Sunday, March 27, 2011 4:19 PM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] IronRuby not loading DLL

I figured that it's always nice to have options - especially if there 
are conflicts.  Capitalizing the first letter would probably work in 99% 
of cases, but I could imagine there might be case where you have an xFoo 
type and an XFoo type in the same namespace.

That's probably being pedantic though - just capitalizing the first 
letter sounds like a pragmatic solution to me.

-Charles
On Sat, Mar 26, 2011 at 10:01 PM, Tomas Matousek 
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>> 
wrote:
What would such block usually do? Uppercase the first letter of a 
lower-cased class/namespace? We could do that or some other mangling 
automatically. Is there any value in customizing the mangling?

Being it automatic would help you to discover the constants since they 
would appear in Module#constants.

Tomas

From: 
ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org> 
[mailto:ironruby-core-bounces@rubyforge.org<mailto:ironruby-core-bounces@rubyforge.org>] 
On Behalf Of Charles Strahan
Sent: Saturday, March 26, 2011 10:00 AM

To: ironruby-core@rubyforge.org<mailto:ironruby-core@rubyforge.org>
Subject: Re: [Ironruby-core] IronRuby not loading DLL

Tomas, how would you feel about adding an optional block param to 
require/load_assembly for overriding how .NET types are mapped to 
constants?  That might be prove beneficial in cases such as these.

-Charles

On Fri, Mar 25, 2011 at 5:37 PM, Tomas Matousek 
<Tomas.Matousek@microsoft.com<mailto:Tomas.Matousek@microsoft.com>> 
wrote:
You need to use const_get to access classes/namespaces whose names are 
not compatible with Ruby naming conventions.
A module in Ruby must start with capital ASCII letter.

const_get(:mdMATCHUPOBJECTLib).const_get(:mdMUIncrementalClass).new 
should work.

Tomas

>
> You can always use const_get for the 1% cases. IMO, having non-capitalized
> namespaces and classes is already 1% case, since such libraries violate .NET
> design guidelines.


That's a valid point.  I't would be trivial to write a script to re-map
types to Ruby constants in the 1% case; my suggestion is probably not 
worth
implementing in IronRuby directly.

-Charles

On Sun, Mar 27, 2011 at 8:44 PM, Tomas Matousek <

>I could imagine there *might* be case where you have an xFoo type and an
XFoo type in the same namespace
BTW, differentiating types or public members by case isn't CLS 
compliant,
which basically means that who ever wrote that code should be expecting 
some
interop issues.


Miguel A. Madero Reyes
www.miguelmadero.com (blog)
me@miguelmadero.com


On Mon, Mar 28, 2011 at 7:19 AM, Charles Strahan <