[IronPython] defined in multiple assemblies (framework 3.5)

[Dody Gunawinata]

Hi Curt,

I hope your team talk to the ASP.Net MVC/IronPython for ASP.Net guys that
are working on putting dynamic support language for ASP.Net.

If this namespace collision does not retard those projects and its users to
be able to utilize .Net 3.5 framework library, then this problem is only a
PITA but not a deal breaker.

The issue that affects the current .Net 3.5 websites are two folds:

1. The presence of Microsoft.Scripting.Core wreak havoc on the .Net 3.5 code
behind code by preventing people using standard System.Core libraries
(Dino's workaround will work on this, but that's why suggestion No.1 does
not work)
2. This eliminates an XCOPY deployment scenario because we have to install
Microsoft.Scripting.dll to the GAC and you have to specify an absolute path
in the /reference: compiler options to make it work.


*"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. "
*
If you are planning for the future, this fact is going to change pretty
soon. .Net 3.5 was released 6 months ago and the new adopter of DLR will be
.Net 3.5 guys.

Dody G.

On Thu, Aug 21, 2008 at 8:43 AM, Curt Hagenlocher <curt at hagenlocher.org>wrote:

> 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
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>


-- 
nomadlife.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080821/37ffa9cf/attachment.html>