You can change all that from code as well.
ScriptRuntimeSetup is what you're interested in
http://github.com/casualjim/ironrubymvc/blob/master/IronRubyMvc/Core/RubyEngine.cs#L412

You can add load paths too from C#
http://github.com/casualjim/ironrubymvc/blob/master/IronRubyMvc/Core/RubyEngine.cs#L365

Adding stuff to the registry is always wrong IMO. The reason being that the
registry only exists on windows and maybe for you that isn't a problem. In
european governments it's not allowed to use windows for many of the
applications (I'm sure most of you know about the great relationship between
the EU and MSFT) so they run linux with mono.  In my country that amounts to
about 30% of the entire IT infrastructure/employment.  The config problem is
a trivial problem at best, and I don't think this issue is ironruby
specific.

Deploying stuff with registry keys almost forces you to use an installer,
which makes the process of scripting the installation of an entire
environment less than optimal for example ( I don't do system images because
they get stale and are bound to specific hardware).

I could do a long rant on this subject, but in comparison to 95% of the
software I get to deal with in an enterprise environment has at least 5x the
configuration requirements from IronRuby.  Let's look at this closer this
whole thread is about < 10 f'ing lines of XML.

Less than 10 lines people, have you ever set up
asp.netmvc/WCF/windsor/unity/....?  So I think instead of complaining
you should be
happy with what the IronRuby team accomplished.
Would you rather have the default values hard-coded then, because that's
such a great solution <sarcasm/>?

<configSections>
    <section name='microsoft.scripting' requirePermission='false'
type='Microsoft.Scripting.Hosting.Configuration.Section,
Microsoft.Scripting, Version=0.9.6.20, Culture=neutral,
PublicKeyToken=null'/>
  </configSections>

  <microsoft.scripting>
    <languages>
      <language extensions='.py' displayName='IronPython 2.6'
type='IronPython.Runtime.PythonContext, IronPython, Version=2.6.10920.0,
Culture=neutral, PublicKeyToken=null' names='IronPython;Python;py'/>
      <language extensions='.rb' displayName='IronRuby'
type='IronRuby.Runtime.RubyContext, IronRuby, Version=0.9.3.0,
Culture=neutral, PublicKeyToken=null' names='IronRuby;Ruby;rb'/>
    </languages>

    <options>
      <set language='Ruby' option='LibraryPaths'
value='..\lib\IronRuby;..\lib\ruby\site_ruby\1.8;..\lib\ruby\site_ruby;..\lib\ruby\1.8'/>
    </options>
  </microsoft.scripting>

---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)



On Sat, Jan 16, 2010 at 6:46 AM, Orion Edwards <orion.edwa...@gmail.com>wrote:

> While I agree that changing the app.config is a common task, and it's easy
> if you're just shipping a single standalone app, it's a *giant* pain in
> the ass if you're having to upgrade an existing installation, or integrate
> with another program. (Outlook.exe.config anyone??)
> I've seen a fair few .net apps move their configuration OUT of app.config
> and into the registry because of things like that.
>
> Is there a way that we can set the library path and other such things
> programatically (eg: RubyEngine.LoadPath = "blah"), etc? That would be much
> nicer than app.config mangling :-(
>
> Cheers, Orion
>
>
>
> On 16/01/2010, at 8:09 AM, Jimmy Schementi wrote:
>
> This configuration, setting different paths etc is too much a hassle for
> developers.
>
>
> Let's go over what "configuration, setting different paths etc" actually
> means:
>
> - When using ir.exe directly?
>
>  Nothing, the Ruby standard library just works.
>
> - When embedding IronRuby inside a .NET app?
>
>  Just telling your C# app where IronRuby's libraries are:
>  1. Copy ir.exe.config into your app.config
>  2. Make sure LibraryPaths still make sense. Making these full-paths is
> easiest,
>     So just replace the ".." with "C:\IronRuby" (or wherever you extracted
> a IronRuby
>     release to ... for example this is the LibraryPaths for a C:\IronRuby
> installation:
>
>     
> C:\IronRuby\lib\IronRuby;C:\IronRuby\lib\ruby\site_ruby\1.8;C:\IronRuby\lib\ruby\site_ruby;C:\IronRuby\lib\ruby\1.8
>
> And that's it. So please, let me know how this could be too much hassle for
> you.
> Sure, embedding isn't "one-click", but don't blow it up to be more than it
> really is.
> Please let us know if you've found any real ship-stopping bugs.
>
> Note that ir.exe.config uses relative paths as we have no idea where
> someone will
> unzip the release to. With the MSI we can possibly generate ir.exe.config
> to use
> full paths, but that would be very low on our list of stuff to do for 1.0.
> Also,
> if we release VS integration in the future, generating the correct
> app.config
> for embedding is also a possibility.
>
> However, for embedding, presumably you are going to want to put the
> libraries
> into your application's directory, so you do really care about where the
> paths
> are, which is why we don't somehow magically find them.
>
> ~Jimmy
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core

Reply via email to