BTW: I don’t see how moving configuration from .config file to registry
helps anything. There is an API for updating .config files as there is
an API for updating registry.
When integrating with another .NET program you just insert IronRuby/DLR
specific section into the existing .config file and you’re done. Outlook
isn’t a managed app and thus hosts CLR via native hosting APIs. In that
case it’s up to the host how it manages configuration. You can always
load a configuration file yourself if the host doesn’t do it for you.
From: [email protected]
[mailto:[email protected]] On Behalf Of Orion E.
Sent: Friday, January 15, 2010 9:47 PM
To: [email protected]
Subject: Re: [Ironruby-core] rexml/document with IronRuby
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
On 16/01/2010, at 8:09 AM, Jimmy S. wrote:
This configuration, setting different paths etc is too much a hassle for
Let’s go over what “configuration, setting different paths etc” actually
- 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:
- Copy ir.exe.config into your app.config
- Make sure LibraryPaths still make sense. Making these full-paths is
So just replace the “…” with “C:\IronRuby” (or wherever you
extracted a IronRuby
release to … for example this is the LibraryPaths for a
And that’s it. So please, let me know how this could be too much hassle
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
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
if we release VS integration in the future, generating the correct
for embedding is also a possibility.
However, for embedding, presumably you are going to want to put the
into your application’s directory, so you do really care about where the
are, which is why we don’t somehow magically find them.