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: [email protected] [mailto:users- > [email protected]] On Behalf Of Mariano Draghi > Sent: Thursday, August 27, 2009 6:21 AM > To: [email protected] > 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 0.9.0.0, and the patched DLL is > 1.0.0.0 > > 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="0.9.0.0" newVersion="1.0.0.0"/> > </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 > [email protected] > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
