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!
> > 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.NET team 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!
________________________________ From: RubyDOTNET@googlegroups.com [mailto:RubyDOTNET@googlegroups.com] On Behalf Of M. David Peterson Sent: Friday, 14 December 2007 8:00 PM To: RubyDOTNET@googlegroups.com Cc: Jb Evain Subject: Re: Loading multiple files with the same name
My follow-up inline below,
On Dec 14, 2007 2:44 AM, M. David Peterson <xmlhac...@gmail.com<mailto: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?
I don't think we should be trying to merge codes with the same basic name. Logically they are completely unrelated source files that just happen to have the same name, so I believe it's preferable that we treat them as two different assemblies.
The problem is that one ruby program might refer to the first foo.rb as say 'A\foo', while some other ruby program may refer to that same file as say '..\foo' (using a different library search path).
What you are suggesting works fine if we are compiling foo.rb on the fly for use by a particular application, but if foo.rb has been compiled ahead of time into foo.dll, then the name of that assembly probably shouldn't include some arbitrary relative path (as it won't even make it unique amoungst other files with the same basic name).
Cheers, Wayne.
________________________________ From: RubyDOTNET@googlegroups.com [mailto:RubyDOTNET@googlegroups.com] On Behalf Of Nathan Swim Sent: Friday, 14 December 2007 10:09 PM To: RubyDOTNET@googlegroups.com Subject: Re: Loading multiple files with the same name
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.
Yes, I considered that, but my initial experimentation showed that if the assembly file name was different to the assembly name (eg assembly named "foo" stored in file "bar.dll") then .NET had trouble probing and loading it (for example if it was referenced by say a C# project). Otherwise it would be perfect.
We could also name the file foo{guid}.dll and identify it as associated with foo.rb by convention, but that would lead to lots of ugly named files lying around everywhere.
Anyone with a tweak that we could apply to these ideas?
The main problem with using strongly named assemblies isn't the generation of the strong names (we can do that internally and hide the pain), but it forces all other applications and assemblies that want to refer to our Ruby compiled assemblies to also be strongly named!
> -----Original Message----- > From: RubyDOTNET@googlegroups.com > [mailto:RubyDOTNET@googlegroups.com] On Behalf Of Douglas Stockwell > Sent: Saturday, 15 December 2007 1:08 AM > To: public-RubyDOTNET-/JYPxA39Uh5TLH3Mboc...@ciao.gmane.org > Subject: Re: Loading multiple files with the same name
> Isn't it enough to give them a seperate assembly name, but > keep the same file name?
> > 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 16, 2007 4:55 PM, Wayne Kelly <w.ke...@qut.edu.au> wrote:
> The main problem with using strongly named assemblies isn't the generation > of the strong names (we can do that internally and hide the pain), but it > forces all other applications and assemblies that want to refer to our Ruby > compiled assemblies to also be strongly named!
Isn't it the other way around? e.g. I can reference a strongly named assembly and not be required to sign my assembly, but what I can't do is sign my assembly if I reference any other assemblies that are not strongly named. In this regard I don't think that signing the assemblies will cause anyone heart ache, where as not signing them could be a bit of a problem, at least for those who need to sign their assemblies and want to reference any standard libs generated by Ruby.NET.
