Unfortunately the 'ExtensionAttribute' type supplied with IronPython 2 clashes with the version in .NET 3.5 if your project also references the System.Core assembly.
The latest release candidate of IronPython solves this problem by providing a fifth assembly. Harry Pierson (DevHawk) gives us the details:
In IronPython 2.0 Beta 5, there were four DLLs that implement IronPython:
In IronPython, we reference the ExtensionAttribute assembly because we use the C# 3.0 complier but IPy has to be able to run on .NET Framework 2.0 SP1. However, projects that embed IronPython in a .NET 3.5 project (aka C# 3.0 or VB 9.0) will reference System.Core instead. The only reason why you would explicitly use the ExtensionAttribute assembly was that if you, like us, wanted to build your app with .NET 3.5, use extension methods but still be compatible with .NET 2.0 SP1. We’re guessing there aren’t many of our customers doing that, but if you are, explicitly referencing ExtensionAttribute will work just as it does for compiling IronPython itself.
It’s important to remember two things about the Fifth Assembly:
- Never reference System.Core and Microsoft.Scripting.ExtensionAttribute in the same project.
- Always deploy Microsoft.Scripting.ExtensionAttribute.dll as part of any solution that embeds IronPython (or IronRuby or vanilla DLR for that matter), even if you don’t reference it explicitly within your project.
Here's what we recommend as a workaround.
The CodePlex work item that tracks this request now contains a modified version of Microsoft.Scripting.ExtensionAttribute.dll. For this one particular case, where simultaneous referencing of the original version of our assembly and System.Core.dll causes problems, you can replace the "shipping version" of our DLL with the modified version. This will eliminate the "is ambiguous" error message.
The magic that makes this work is called "type forwarding". The updated DLL simply contains a type forwarder to System.Core for the type System.Runtime.CompilerServices.ExtensionAttribute. As a result, there is no second copy of that class, and the CLR loader redirects all references from the rest of IronPython to System.Core.
This file, though strongly-named and signed, is even more "not supported" than the rest of IronPython :). By this I mean primarily that we haven't run any test passes using the new assembly, and don't plan to. However, as it doesn't actually contain any code, the risks from this modified version should be very small.
We hope to address this problem differently for the next release, but our promise to stay compatible with .NET 2.0 for this release has somewhat constrained the type of solution we are able to offer.
Thanks for your patience!