[IronPython] defined in multiple assemblies (framework 3.5)

[Fernando Correia]

Curt, believe me, we all appreciate very much what the dynamic
language teams are doing. It is just great to see such a movement
going on.

But I second Dody's remarks. He said it very well. The first solution
does not work (that's my problem scenario exactly) and the second one
may be too unwieldy.

Well, if the first release of IronPython 2 won't work with .Net 3.5
websites that use the latest language enhancements, then I guess I
will have to reevaluate my options for scripting. Maybe the community
can create a fork of Microsoft.Scripting.Core that would be compatible
with the latest runtime libraries.

2008/8/21 Dody Gunawinata <empirebuilder at gmail.com>:
> 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.