Hi,
With user defined class, if the namespace name start with lower letter
case,
eg.
namespace myhumbleobjects {
public class MyClass {
...
}
}
How to use the class in ruby code ?
-----
require 'myhumbleobjects.dll'
o = myhumbleobjects::MyClass.new # causes 'undefined local variable
or method 'myhumble...'
#or
o = Myhumbleobjects::MyClass.new # causes 'uninitialized constant ...'
------
At this moment, if Ruby.NET doesn't support the lower-cased namespace
(and class ?) , I'd like to propose that Ruby.NET should import the
name with changing the first letter into upper case (eg.
Myhumbleobjects above example) acording with Win32OLE who change the
first letter of the name of the COM object's enum value for Ruby.
> -----Original Message----- > From: RubyDOTNET@googlegroups.com > [mailto:RubyDOTNET@googlegroups.com] On Behalf Of arton > Sent: Sunday, 2 December 2007 2:40 AM > To: Ruby.NET Compiler Discussion > Subject: Does .NET Interop support namespace with lower case letter ?
> Hi, > With user defined class, if the namespace name start with > lower letter case, eg. > namespace myhumbleobjects { > public class MyClass { > ... > } > }
> How to use the class in ruby code ?
> ----- > require 'myhumbleobjects.dll'
> o = myhumbleobjects::MyClass.new # causes 'undefined local variable > or method 'myhumble...' > #or > o = Myhumbleobjects::MyClass.new # causes 'uninitialized constant ...' > ------
> At this moment, if Ruby.NET doesn't support the lower-cased > namespace (and class ?) , I'd like to propose that Ruby.NET > should import the name with changing the first letter into > upper case (eg. > Myhumbleobjects above example) acording with Win32OLE who > change the first letter of the name of the COM object's enum > value for Ruby.
Ruby programs (such as RubyGems) can load multiple source files with the same base name (ifthey are in different directories).
Eg: require 'A\foo' require 'B\foo'
Each of these source files may have already been separately compiled into an assembly. So, directory A might contain an assembly, presumably named foo.dll, as might directory B.
If these assembly files are named foo.dll, then presumably the assemblies will be named "foo".
.NET doesn't allow two assemblies with the same name to be loaded in the same app domain.
This seems to imply that we need to strongly name all of our generated assemblies; and that we will need to use a different (randomly generated) key for signing each assembly.
Retry on this (sent the original messages from the wrong account)--- PLEASE NOTE: Jb has already replied, his follow-up I will attach in a separate follow-up ---
Original Post -------------------
This sounds like exactly what Cecil was designed for. I've Cc'd Jb Evain, Cecil's creator and a member of the Mono Project team.
Jb: Please see Dr. Kelly's overview of the problem at hand below. What do you think? Is Cecil the way to go?
> Ruby programs (such as RubyGems) can load multiple source files with the > same base name (ifthey are in different directories).
> Eg: > require 'A\foo' > require 'B\foo'
> Each of these source files may have already been separately compiled into > an assembly. > So, directory A might contain an assembly, presumably named foo.dll, as > might directory B.
> If these assembly files are named foo.dll, then presumably the assemblies > will be named "foo".
> .NET doesn't allow two assemblies with the same name to be loaded in the > same app domain.
> This seems to imply that we need to strongly name all of our generated > assemblies; > and that we will need to use a different (randomly generated) key for > signing each assembly.
On 12/14/07, M. David Peterson <m.da...@mdptws.com> wrote:
> Jb: Please see Dr. Kelly's overview of the problem at hand below. What do > you think? Is Cecil the way to go?
Nope. Cecil is about being able to read and write assemblies, without being tied to the runtime mechanisms. Cecil can by no mean load assemblies and execute them.
At some point, the RubyDotNet assemblies have to be executed, and if there's two assemblies with the same name, Cecil can't help (except if you decide to patch the assemblies before loading time, to include a random tag at the end of the assembly name, but that doesn't sound like the way to go (either it is patched with Cecil or perwapi), does it?).
> Retry on this (sent the original messages from the wrong account)--- > PLEASE NOTE: Jb has already replied, his follow-up I will attach in a > separate follow-up > ---
> Original Post > -------------------
> This sounds like exactly what Cecil was designed for. I've Cc'd Jb Evain, > Cecil's creator and a member of the Mono Project team.
> Jb: Please see Dr. Kelly's overview of the problem at hand below. What do > you think? Is Cecil the way to go?
> On Dec 13, 2007 11:40 PM, Wayne Kelly <w.ke...@qut.edu.au> wrote:
> > Ruby programs (such as RubyGems) can load multiple source files with the > > same base name (ifthey are in different directories).
> > Eg: > > require 'A\foo' > > require 'B\foo'
> > Each of these source files may have already been separately compiled > > into an assembly. > > So, directory A might contain an assembly, presumably named foo.dll, as > > might directory B.
> > If these assembly files are named foo.dll, then presumably the > > assemblies will be named "foo".
> > .NET doesn't allow two assemblies with the same name to be loaded in the > > same app domain.
> > This seems to imply that we need to strongly name all of our generated > > assemblies; > > and that we will need to use a different (randomly generated) key for > > signing each assembly.
On Dec 14, 2007 2:44 AM, M. David Peterson <xmlhac...@gmail.com> wrote:
> Nope. Cecil is about being able to read and write assemblies, without > being tied to the runtime mechanisms. Cecil can by no mean load > assemblies and execute them.
Right, but could it be used to load two separate assemblies of the same name (of which have two completely different signatures), merge them into one assembly (possibly separating the two using the virtual path as the namespace? e.g. namespace net.http {...} namespace uri.http {...}), save the resulting assembly to disk, and then dereference calls to either 'net/http' or 'uri/http' using the virtual path to map to the namespace? Or am I way out in left field on this one?
> At some point, the RubyDotNet assemblies have to be executed, and if > there's two assemblies with the same name, Cecil can't help (except if > you decide to patch the assemblies before loading time, to include a > random tag at the end of the assembly name, but that doesn't sound > like the way to go (either it is patched with Cecil or perwapi), does > it?).
Not sure. At the moment it seems like the only real solution is generating a random key and then signing each assembly such that they can be loaded in the same appdomain, so if there is a solution that's cheaper than this, then I think it's definitely worth paying some attention to.
I am a complete newbie at this Ruby thing, however, it might work to include the namespace as part of the name of the assembly. So in your example above 'A\foo' would become A.foo.dll and, likewise, 'B\foo' would become B.foo.dll. Where I become quite ignorant in this matter is how the 'require' command works in Ruby.
Nathan Swim
On Dec 14, 2007 4:59 AM, M. David Peterson <xmlhac...@gmail.com> wrote:
> On Dec 14, 2007 2:44 AM, M. David Peterson <xmlhac...@gmail.com> wrote:
> > Nope. Cecil is about being able to read and write assemblies, without > > being tied to the runtime mechanisms. Cecil can by no mean load > > assemblies and execute them.
> Right, but could it be used to load two separate assemblies of the same > name (of which have two completely different signatures), merge them into > one assembly (possibly separating the two using the virtual path as the > namespace? e.g. namespace net.http {...} namespace uri.http {...}), save > the resulting assembly to disk, and then dereference calls to either > 'net/http' or 'uri/http' using the virtual path to map to the namespace? Or > am I way out in left field on this one?
> > At some point, the RubyDotNet assemblies have to be executed, and if > > there's two assemblies with the same name, Cecil can't help (except if > > you decide to patch the assemblies before loading time, to include a > > random tag at the end of the assembly name, but that doesn't sound > > like the way to go (either it is patched with Cecil or perwapi), does > > it?).
> Not sure. At the moment it seems like the only real solution is > generating a random key and then signing each assembly such that they can be > loaded in the same appdomain, so if there is a solution that's cheaper than > this, then I think it's definitely worth paying some attention to.
> Ruby programs (such as RubyGems) can load multiple source files with the same base name (ifthey are in different directories).
> Eg: > require 'A\foo' > require 'B\foo'
> Each of these source files may have already been separately compiled into an assembly. > So, directory A might contain an assembly, presumably named foo.dll, as might directory B.
> If these assembly files are named foo.dll, then presumably the assemblies will be named "foo".
> .NET doesn't allow two assemblies with the same name to be loaded in the same app domain.
> This seems to imply that we need to strongly name all of our generated assemblies; > and that we will need to use a different (randomly generated) key for signing each assembly.
> Well, there is a of course a jillion of possibilities. Thing is that > as Ruby's require have different semantic that assembly.load*, I think > that it's the compiler task to handle 'require' to not accept compiled > assemblies but to rather compile themselves relatively to the code > that 'require' something.
Not sure I completely understand. Are you suggesting that facilitating the loading of pre-compiled assemblies (e.g. foo.rb and foo.dll are in the same directory, foo.dll gets loaded if the timestamp is newer than that of foo.rb) is a bad idea? I can see your point from the standpoint of distributing DLL's outside of the directory structure they were compiled against. In fact, I think the way Python handles things presents a perfect use-case, using the compiled .pyc file if and when it's datestamp is newer than it .py source file equivalent, but using the existing relative path directory structure to determine what goes with what. On the flip-side, however, one of key advantages of Ruby.NET is the ability to reference statically compiled Ruby code from within any CLI-compliant language, so while shipping a single .rb file as a DLL might be a bad idea, shipping a complete assembly that that can be referenced from within other languages is obviously a good thing. That said, in the same way that Python has adopted the notion of using eggs (which are just zipped directories that contain the source files in their proper directory structure, replacing .zip with .egg), I wonder if the same general idea shouldn't be considered for Ruby.NET, using embedded resources who's key value is the virtual path of their given directory structure. The avenue that was taking by the ASP.NETteam with the VirtualPathProvider I think presents a perfect example of how well this general idea can be adapted to the .NET platform. e.g. > http://msdn2.microsoft.com/en-us/library/aa479502.aspx < which is an example of serving an entire web site from a single zip file, using the VirtualPathProvider with VirtualFile and VirtualDirectory to decide how each request gets handled. Actually, come to think of it, isn't this wat netmodule's were designed for? I rarely use, nor rarely do I see netmodule's being used, but if not mistaken, wasn't the original design to allow the ability to compile, for example, a VB.NET project into a netmodule, a C# project into a netmodule, and then merge the two (or more) together into one assembly for distribution?
I think Cecil is the heavy gun solution here.
And you would certainly be the one qualified to make that determination ;-) Thanks for the feedback, Jb!
