Hello,
I’ve just been playing around with IronRuby and VS2010. If I
understand the situation correctly, Microsoft.Scripting.Core has been
integrated into .Net 4.0, leaving Microsoft.Scripting to hold the Ast
and the Hosting API?
Because of this, you can only use a particular build of IronPython
(http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448).
As a result, you can’t use IronRuby yet because there isn’t an
assiocated build using the same DLR engine?
This seems quite a strong dependency between .Net and the DLR. Only
allowing particular builds of the langauge to work against a
particular version of the framework sounds like it will be a nightmare
to manage. Are we going to be in the position where we have a
Community\Bleeding Edge Build and .Net framework build?
Is this going to change in the next beta \ CTP?
Thanks
Ben
Your understanding of the situation is basically correct.
Internally, we call the parts of the DLR that are in
Microsoft.Scripting.Core.dll the “inner ring” and the parts that are in
Microsoft.Scripting.dll the “outer ring”. The bits in the inner ring
are pretty stable; its functionality was defined some time ago and is
relatively nailed down now. There have been bug fixes and small
changes, but for the most part we’re pretty happy with the specific
features that it contains. There will undoubtedly continue to be small
changes between now and the time that CLR4 is released.
Given that we will want people to be able to play with the dynamic
features in C# and VB, I’m sure we’ll release builds of the languages
that correspond with subsequent CTPs and betas of CLR4/VS2010. But we
may again have to use slightly older versions of the sources. The
reason there was no build of IronRuby for the first CTP was that its
snapshot was taken at the end of August, when IronRuby didn’t yet
support IDynamicObject.
“DLR 1.0” is expected to contain the finalized bits from CLR4. This
means that language source which builds against DLR 1.0 (for CLR2) will
also build against CLR4. Everything should be sync’d up and happy.
It’s too early to speculate on a post-DLR-1.0 world, but it’s reasonable
to assume that we’ll have similar issues as more functionality migrates
from the outer ring to the inner ring of the DLR. But I expect that the
CLR2+DLR1/CLR4 platform ought to be a stable base to build languages
from for some time.
Hi Curt,
Thanks for the reply, seems to make sense. So it sounds like once CLR4
is RTM, it won’t be so much of a problem which is good… For now,
I’ll just use IronPython 
Cheers
Ben