# IronRuby.Ruby.GetExecutionContext removed **URL:** \ **Category:** IronRuby\ **Created:** [March 5, 2010, 2:32am UTC](https://www.ruby-forum.com/t/ironruby-ruby-getexecutioncontext-removed/184601 "2010-03-05T02:32:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jsoho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8baadc/32.png) [@jsoho](https://www.ruby-forum.com/u/jsoho)\ **Post date:** [March 5, 2010, 2:32am UTC](https://www.ruby-forum.com/t/ironruby-ruby-getexecutioncontext-removed/184601/1 "2010-03-05T02:32:02Z")
including the mailing list as people might run into this … Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is there any other way to get to the instance of IronRuby.Ruby.RubyContext? I’d presume anyone hosting IronRuby and define ruby global variables was using DefineGlobalVariable; so they’d run into this. Looks like ScriptEngine.LanguageContext is now internal as well … I specifically found this while updating DLRConsole, and simply removed the places where I was using ruby global variables. ---
**Author:** ![jsoho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8baadc/32.png) [@jsoho](https://www.ruby-forum.com/u/jsoho)\ **Post date:** [March 8, 2010, 11:28am UTC](https://www.ruby-forum.com/t/ironruby-ruby-getexecutioncontext-removed/184601/2 "2010-03-08T11:28:25Z")
Tomas, What reasons did we have for removing this in the first place? It also affects anyone writing code that uses our Ruby types/library methods in their own code (for providing the correct types to Ruby code); IronRuby.Rack does this. As a work-around, are we really expecting people to use Microsoft.Scripting.Hosting.Providers.HostinHelpers.GetLanguageContext directly? ~Jimmy From: Jimmy S. Sent: Thursday, March 04, 2010 5:32 PM To: Tomas M. Cc: removed\_email\_address@domain.invalid Subject: IronRuby.Ruby.GetExecutionContext removed including the mailing list as people might run into this … Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is there any other way to get to the instance of IronRuby.Ruby.RubyContext? I’d presume anyone hosting IronRuby and define ruby global variables was using DefineGlobalVariable; so they’d run into this. Looks like ScriptEngine.LanguageContext is now internal as well … I specifically found this while updating DLRConsole, and simply removed the places where I was using ruby global variables. ---
**Author:** ![jsoho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8baadc/32.png) [@jsoho](https://www.ruby-forum.com/u/jsoho)\ **Post date:** [March 8, 2010, 11:55am UTC](https://www.ruby-forum.com/t/ironruby-ruby-getexecutioncontext-removed/184601/3 "2010-03-08T11:55:21Z")
By the way, if anyone is depending on IronRuby.Ruby.GetExecutionContex, your code will break when built/run against the HEAD of the sources. As a work-around, here’s the implementation of GetExecutionContext which you can just use in your own code: ``` using Microsoft.Scripting.Hosting; using Microsoft.Scripting.Utils; using IronRuby.Runtime; // ... public static RubyContext GetExecutionContext(ScriptEngine ``` engine) { ContractUtils.RequiresNotNull(engine, “engine”); var context = Microsoft.Scripting.Hosting.Providers.HostingHelpers.GetLanguageContext(engine) as RubyContext; if (context == null) { throw new InvalidOperationException(“Given engine is not a Ruby engine”); } return context; } ``` public static RubyContext GetExecutionContext(ScriptRuntime ``` runtime) { ContractUtils.RequiresNotNull(runtime, “runtime”); return GetExecutionContext(Ruby.GetEngine(runtime)); } Let us know if you use this, and what you use it for, so we can figure out whether removing it is the right call. ~Jimmy From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Jimmy Schementi Sent: Monday, March 08, 2010 2:27 AM To: Tomas M. Cc: ‘removed\_email\_address@domain.invalid’ Subject: Re: [Ironruby-core] IronRuby.Ruby.GetExecutionContext removed Tomas, What reasons did we have for removing this in the first place? It also affects anyone writing code that uses our Ruby types/library methods in their own code (for providing the correct types to Ruby code); IronRuby.Rack does this. As a work-around, are we really expecting people to use Microsoft.Scripting.Hosting.Providers.HostinHelpers.GetLanguageContext directly? ~Jimmy From: Jimmy S. Sent: Thursday, March 04, 2010 5:32 PM To: Tomas M. Cc: removed\_email\_address@domain.invalid Subject: IronRuby.Ruby.GetExecutionContext removed including the mailing list as people might run into this … Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is there any other way to get to the instance of IronRuby.Ruby.RubyContext? I’d presume anyone hosting IronRuby and define ruby global variables was using DefineGlobalVariable; so they’d run into this. Looks like ScriptEngine.LanguageContext is now internal as well … I specifically found this while updating DLRConsole, and simply removed the places where I was using ruby global variables. ---
**Author:** ![jsoho](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/8baadc/32.png) [@jsoho](https://www.ruby-forum.com/u/jsoho)\ **Post date:** [March 8, 2010, 5:55pm UTC](https://www.ruby-forum.com/t/ironruby-ruby-getexecutioncontext-removed/184601/4 "2010-03-08T17:55:21Z")
We removed it for 2 reasons: 1. ``` RubyContext is not a supported public API and can change any ``` time. Hosting APIs on the other hand (i.e. IronRuby.Ruby class) will remain stable. We’ll try hard not to introduce breaking changes. 1. ``` RubyContext is not remoting aware while Hosting APIs are. ``` HostingHelpers.GetLanguageContext can be used as a last resort workaround, however there is no guarantee we won’t break such usage any time in future by changing RubyContext. What methods on RubyContext does IronRuby.Rack need? If there is some feature that should be exposed via Hosting API we should add it. Tomas From: Jimmy S. Sent: Monday, March 08, 2010 2:27 AM To: Tomas M. Cc: ‘removed\_email\_address@domain.invalid’ Subject: RE: IronRuby.Ruby.GetExecutionContext removed Tomas, What reasons did we have for removing this in the first place? It also affects anyone writing code that uses our Ruby types/library methods in their own code (for providing the correct types to Ruby code); IronRuby.Rack does this. As a work-around, are we really expecting people to use Microsoft.Scripting.Hosting.Providers.HostinHelpers.GetLanguageContext directly? ~Jimmy From: Jimmy S. Sent: Thursday, March 04, 2010 5:32 PM To: Tomas M. Cc: removed\_email\_address@domain.invalid Subject: IronRuby.Ruby.GetExecutionContext removed including the mailing list as people might run into this … Tomas, I know you recently removed IronRuby.Ruby.GetExecutionContext; is there any other way to get to the instance of IronRuby.Ruby.RubyContext? I’d presume anyone hosting IronRuby and define ruby global variables was using DefineGlobalVariable; so they’d run into this. Looks like ScriptEngine.LanguageContext is now internal as well … I specifically found this while updating DLRConsole, and simply removed the places where I was using ruby global variables.