There’s a lot of new stuff here, from new versions of IronRuby,
IronPython, Managed JScript, and the Dynamic Languages Runtime, to more
sample. Also, there are now three packages: SDK, SDK Samples, and SDK
Source.
* SDK: Necessary package to create dynamic language Silverlight
applications.
* SDK Samples: a bunch of Ruby, Python, and JScript samples. Best
bet is to unzip this in the SDK directory.
* SDK Source Code: If you want to modify the
languages/DLR/Silverlight integration, you can do so here, and build
using the given Solution file in Visual Studio. This will create a /bin
directory with the identical binaries as the /bin directory in the SDK,
however without DLL signing.
Sweet. That means I can compile my dynamic script control for the all
the DLR based languages.
On Wed, Jun 11, 2008 at 9:29 AM, Ben H.
<[email protected]mailto:[email protected]> wrote:
Excellent!! A new set of IronPython, IronRuby and DLR assemblies. I
can actually get my app working tonight!
SDK Samples: a bunch of Ruby, Python, and JScript samples. Best bet is to unzip this in the SDK directory.
SDK Source Code: If you want to modify the languages/DLR/Silverlight integration, you can do so here, and build using the given Solution file in Visual Studio. This will create a /bin directory with the identical binaries as the /bin directory in the SDK, however without DLL signing.
Sweet. That means I can compile my dynamic script control for the all
the DLR based languages.
On Wed, Jun 11, 2008 at 9:29 AM, Ben H.
<[email protected]mailto:[email protected]> wrote:
Excellent!! A new set of IronPython, IronRuby and DLR assemblies. I
can actually get my app working tonight!
SDK Samples: a bunch of Ruby, Python, and JScript samples. Best bet is to unzip this in the SDK directory.
SDK Source Code: If you want to modify the languages/DLR/Silverlight integration, you can do so here, and build using the given Solution file in Visual Studio. This will create a /bin directory with the identical binaries as the /bin directory in the SDK, however without DLL signing.
Sweet. That means I can compile my dynamic script control for the all
the DLR based languages.
On Wed, Jun 11, 2008 at 9:29 AM, Ben H.
<[email protected]mailto:[email protected]> wrote:
Excellent!! A new set of IronPython, IronRuby and DLR assemblies. I
can actually get my app working tonight!
SDK Samples: a bunch of Ruby, Python, and JScript samples. Best bet is to unzip this in the SDK directory.
SDK Source Code: If you want to modify the languages/DLR/Silverlight integration, you can do so here, and build using the given Solution file in Visual Studio. This will create a /bin directory with the identical binaries as the /bin directory in the SDK, however without DLL signing.
No it’s for xaml and eventually silverlight too probably.
At the moment I only have a little experiment online and I’m now the
more
useful version.
Anyway I wanted a way to write my controls in IronRuby and then have
them
participate in a xaml layout as any CLR based control can do. At this
moment
I’ve made it so that you set the properties on the DLR based control
with a
language specific hash/dictionary. So if you use it in python you set
the
properties on the control using a python dictionary or at least that’s
the
plan but for that I needed a common DLR which I have now.
I just created a new project build target which doesn’t define the
silverlight constant and then I had to replace the references to the
silverlight assemblies in Microsoft.Scripting.Core and
Microsoft.Scripting.
I also unchecked Chiron and Microsoft.Scripting.Core.Silverlight but
that
isn’t necessary if you don’t want to use build solutiion.
I’ve sent you the files. Now to answer the question as to why there is
a
need for building against different assemblies. Because Silverlight
includes
the CoreCLR something like a CLR lite it has a different mscorlib
with
less stuff in it. Since mscorlib is the base library of the CLR you
need to
have a different build for everything that relies on that CLR lite.
Which
is why you need a different System and so on.
So when you just use one or the other visual studio will take care of
selecting the appropriate assemblies for you. In this case you had to do
it
manually. I don’t think that will change in the future, what will change
is
that you will be able to download IronRuby or IronPython or so and you
can
then be sure that both rely on the same DLR so that you can support any
of
those languages.
I have this method:
public string GetSaveFilter()
{
string filter = string.Empty;
foreach (string ext in Engine.GetRegisteredExtensions())
{
filter += string.Format("{0}|*{1}",
Engine.LanguageDisplayName, ext);
}
return filter;
}
This was for my save dialog so I could have IronPython|*.py. However,
with this release GetRegisteredExtensions doesn’t seem to be working
the same.
If I look in my Quick Watch window, what I get is (Engine ==
ScriptEngine):
