IronPython 2 and the Fifth Assembly
IronPython 2 uses Dynamic Language Runtime expression trees, which have been merged with LINQ expression trees. These have extension methods and IronPython itself also uses extension methods. These need the .NET 3.5 compiler, but if you provide an 'ExtensionAttribute' type then the compiled assemblies still work with .NET 2 (extension methods are effectively a compiler trick).
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: The important details are:
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:
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!
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: The important details are:
In IronPython 2.0 Beta 5, there were four DLLs that implement IronPython:
- IronPython.dll
- IronPython.Modules.dll
- Microsoft.Scripting.dll
- Microsoft.Scripting.Core.dll
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!
Comments
Post a Comment