You can load different versions of assemblies in a different appdomain.
The question is what do you pass the main appdomain back. Are you
going to pass it back a DLR component or are you just going to pass
back the clr object that is the result of your script.. because my
guess would be that a CLR object would be just fine but a DLR object
might pose some problems.
Mind you I'm just guessing here I haven't tested any of this, except
for loading different version of assemblies in appdomains. I would
think you could pass it the script string or path and then get the clr
type back from the execution in the main app domain. And I also
haven't tested yet wheter you can actually call properties and methods
on a DLR object if it isn't known before in the CLR.
And as Michael said before it smells :) It feels very wrong to me to
have to do this and I've been known to say things like _ why? because
I can._ I just think this isn't one of those cases.
Cheers
Ivan
On 26/05/2008, at 11:26 AM, Ben Hall wrote:
Hi Ivan,
I think this would only work if you completely abstract away from
the DLR.
My initial problem with that is this:
Main AppDomain references 1.0.0.2000 to use ScriptRuntime etc
IPAppDom refereences 1.0.0.2000. Crossing AppDomain boundaries isn't
a problem because they are the same version.
RubyAppDoman references 1.0.0.0. When you have to pass your
ScriptRuntime (Engine, Scope whatever) back to the main appdomain I
think it will throw an exception.
Not having used AppDomains in a long time I might be wrong :)
Ben
On Sun, May 25, 2008 at 11:56 PM, Ivan Porto Carrero
<[EMAIL PROTECTED]> wrote:
You could treat it like plugins.
that is have a rubybin folder and a pythonbin folder
Load the correct assemblies in a different appdomain execute your
code there
and get the result back.
For Michael this idea isn't new :) I'll that later this week in our
dynamic
script control to see how that works out.
Any other more simple and elegant solutions are welcome of course
Cheers
Ivan
On 26/05/2008, at 9:58 AM, Michael Foord wrote:
Hello Ben,
I don't have an answer, just to say that I have the same problem.
For our 'Dynamic Script Control' project we would like to develop
(and
test with) for both IronPython and IronRuby.
This makes project structure "problematic".
I realise that at some point this will be a non-problem, but in the
meantime if anyone has any good ideas I'd like to hear them...
Michael Foord
Ben Hall wrote:
Hello,
Posted similar message onto IronRuby but I thought I would also ask
you guys. My scenario is that I need to host IronRuby and
IronPython
within the same application. I thought this would be easy as they
both
are based on the DLR.
However, you both appear to be at different stages of the DLR
life and
building against different sources. Is this the same internally?
At
the moment I can't see a way I can build both IronPython and
IronRuby
from the same DLR assemblies?
At some point, I take it the DLR will merge into a single release
and
known assembly for other language providers and hosts to use
instead
of multiple different versions?
In the mean time - what can I do? Is anyone doing this?
Thanks
Ben
Blog.BenHall.me.uk
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.theotherdelia.co.uk/
http://www.voidspace.org.uk/
http://www.ironpython.info/
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
