[IronPython] IPy 2.x and ASP.NET 3.5

Dino Viehland dinov at microsoft.com
Thu Aug 27 16:19:41 CEST 2009

To get around the signing issues you can run "sn -Vr Microsoft.Scripting.ExtensionAttribute.dll" on
your built version if you build it w/ our public key.  The public key is in our source distributions
as "MSSharedLibKey.snk".

I had intended for 2.6 to be lined up w/ the previously shipped extension DLL but it looks like
it's not.  We should also put out an updated DLL for 2.0.3 - I'll look into doing that.

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Mariano Draghi
> Sent: Thursday, August 27, 2009 6:21 AM
> To: users at lists.ironpython.com
> Subject: [IronPython] IPy 2.x and ASP.NET 3.5
> Hi there,
> After many hours running different experiments, I still can't find a
> way to embed IronPython 2.x in a ASP.NET 3.5 web site.
> I have read this:
> http://ironpython-urls.blogspot.com/2008/10/ironpython-2-and-fifth-
> assembly.html
> and this:
> http://devhawk.net/2008/10/21/The+Fifth+Assembly.aspx
> and tried the solution on this CodePlex workitem:
> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19126
> ... but nothing works.
> If I use the "shipped" Microsoft.Scripting.ExtensionAttribute.dll, I
> get the "ambiguous..." compilation error that originated the workitem
> 19126
> If I use the "modified" Microsoft.Scripting.ExtensionAttribute.dll
> attached to the workitem, it refuses to be loaded. When I try to
> instantiate the engine, I get an error telling me that the
> Microsoft.Scripting.ExtensionAtribute cannot be loaded. It seems that
> IronPython 2.0.2 expects versions, and the patched DLL is
> I tried to solve the last issue using a "dependentAssembly" node in
> the web.config, like this:
>       <dependentAssembly>
>         <assemblyIdentity
> name="Miscrosoft.Scripting.ExtensionAttribute"
> publicKeyToken="31bf3856ad364e35" culture="neutral" />
>         <bindingRedirect oldVersion="" newVersion=""/>
>       </dependentAssembly>
> ... but it doesn't work either. The DLL cannot be loaded.
> I tried to compile my own Microsoft.Scripting.ExtensionAttribute.dll
> using the "type forwarding" trick mentioned in Michaeld's post, but
> then I run into signing issues, and my DLL can't be loaded.
> I even tried a suggestion discused here some time ago, about
> recompiling IronPython taking away the
> Microsoft.Scripting.ExtensionAttribute project, and using 3.5 as a
> target (adding references to System.Core), but it seems it is not as
> simple as that: As soon as I start changing targets, I start getting
> more and more "collitions" with System.Core and IronPython's own
> implementations.
> So, in a nuthshell, I downgraded to IPy 1.1 (and I *hate* having to do
> that!), which is old, but works like a charm.
> But I *really, really* would like to find a proper solution to this,
> or at least a workarround that... *works*, without having to mess
> around with IronPython's source code.
> I'm very sad because this problem is also reproducible with the last
> beta of IPy 2.6, so it seems we're going to get another major release
> that cannot play well with ASP.NET 3.
> Is there anything I can do yo embed IronPython 2 in a ASP.NET 3.5
> application?
> Thank you very much,
> --
> Mariano
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

More information about the Ironpython-users mailing list