[IronPython] defined in multiple assemblies (framework 3.5)

[Curt Hagenlocher]

I know that to the outside, Microsoft looks like a big company with a lot of
people.  And of course, it is!  But the number of people working on dynamic
languages is pretty small, and we have to carefully decide where our
resources will serve the largest number of users and potential users.

There are two kinds of changes that have been made to the DLR over the past
months.  The bulk of the work involves features -- including ironing out the
hosting interfaces and finding the right balance between parts that belong
in the shared DLR and parts that belong in the individual languages.  But
the other type of changes have been more forward-looking -- they're there to
support future releases of other Microsoft projects.  It's one of those
changes that is causing this namespace collision between
Microsoft.Scripting.Core.dll and System.Core.dll.

Now, the DLR team can't just tell those other projects that "sorry, you'll
have to wait for the changes you need" because they've already made a
commitment with dates and deadlines.  IronPython could have chosen to "fork"
the DLR code at a point before these changes were made.  But this would mean
that someone would have to regularly review the changes and fixes made on
the main line of DLR development and integrate those back into IronPython's
private copy.  We do not believe that the benefit to our users justifies the
level of effort required to do this.  We think that most of our users would
prefer us to focus our resources on more tangible benefits like improving
performance and compatibility with CPython.

This namespace collision only affects those who are using both the hosting
interfaces and System.Core features in the same project.  We believe this to
be a fairly small percentage of all IronPython users.  And for most such
projects, the workaround is fairly simple -- if it weren't, we probably
wouldn't have gone down this route.  But what you've identified is that we
did not realize that the solution for "Web Site" projects would be both
different and more complicated than the workaround for other project types.

The situation is almost certainly not going to change by the time IronPython
2.0 is released.  In order to use both System.Core and the DLR in the same
"Web Site" project, you will have to do one of two things:

1) Keep the DLR hosting pieces in a separate "Class Library" project and
incorporate the output .DLL of this project into your "Web Site" project, or
2) Use the workaround that Dino posted. I assume your comment about "loss of
Intellisense" is strictly for the DLR; I would guess that it's because the
language service doesn't know that it needs to extract the DLR alias
information from web.config.

In a more ideal world, we wouldn't need these workarounds.  Nonetheless,
neither seems particularly onerous to me.  If you feel strongly that this is
something which needs to be changed, please add a item to CodePlex to track
the request.  We use the number of votes that each item gets in order to
track the level of support it has in the community.  This, in turn, helps us
to gauge how our efforts can best serve our users.

Thanks,
-Curt


On Wed, Aug 20, 2008 at 12:56 PM, Fernando Correia <
fernandoacorreia at gmail.com> wrote:

> I spent some time trying to create a version of
> Microsoft.Scripting.Core that is compatible with the framework 3.5.
> But I gave up because it is a huge job and in ambiguous cases I can't
> be sure if I should use the original classes in System.Core or the new
> duplicated classes in Microsoft.Scripting.Core. I'm amazed that
> Microsoft is releasing an assembly like this, even in beta. I must be
> missing something.
>
> Dody, if you have a version of Microsoft.Scripting.Core that is
> compatible with the 3.5 framework I'd like to give it a try.
>
> 2008/8/20 Dody Gunawinata <empirebuilder at gmail.com>
> >
> > I can confirm that this works, one just have to kiss intellisense support
> goodbye though. Thanks for the effort.
> >
> > If anyone interested, I have a copy of refactored namespace for IP Beta 4
> (It compiles and runs on a test site, but I haven't tried it =on my product
> application yet)
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080820/2406a819/attachment.html>