Good Morning guys, me again :-) So today I'm dealing with TFS, and trying to add a method to a CLR type, as follows:
class Microsoft::TeamFoundation::Build::Client::BuildServer def query_single_build(spec) self.query_builds(spec).builds.first end end I then get an instance of this class by doing build_server = tfs.get_service IBuildServer.to_clr_type however, some strange things happen. Firstly, the query_single_build method isn't available, and secondly, the class doesn't match. Here's an interesting paste from irb >>> build_server => Microsoft.TeamFoundation.Build.Client.BuildServer >>> build_server.class => Microsoft::TeamFoundation::Build::Client::BuildServer >>> build_server.class == Microsoft::TeamFoundation::Build::Client::BuildServer => false Microsoft::TeamFoundation::Build::Client::BuildServer.to_clr_type => nil What appears to be happening here is that Microsoft.TeamFoundation.Build.Client.BuildServer is an internal class inside the TFS dll's, and so IronRuby is transparently creating a new ruby-only Microsoft::TeamFoundation::Build::Client::BuildServer class. Technically this is probably correct, but it's *incredibly* confusing. I only came to this conclusion by digging around in reflector for a while, and I'm not really sure if it's actually what's happening So, is my guess correct, and is there anything that could be done to clarify this in future? IIRC ruby 1.9 has a 'shadowing' warning that happens when you shadow a method variable with a local variable - perhaps this could be emitted when IronRuby is 'shadowing' a private clr class instead of extending it? For posterity, I solved it by extending the public IBuildServer interface instead of the class. module Microsoft::TeamFoundation::Build::Client::IBuildServer def ...
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
