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/Project...). 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
on 2009-01-04 15:57
on 2009-01-04 18:54
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.
on 2009-01-04 19:17
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