clr - .NET 2.0中具有扩展属性的Escape Catch-22

Question

如何同时针对2.0、3.0、3.5、4.0和4.5的单个.NET程序集支持C#和VB.NET使用者的扩展方法？

标准建议是添加以下内容:

namespace System.Runtime.CompilerServices
{
  public sealed class ExtensionAttribute : Attribute { }
}

这种方法由 more提出，而不是 one Microsoft employee提出，甚至在 MSDN magazine中得到了体现。 widely称赞 many bloggers具有“无不良影响”。

哦，除了会导致VB.NET项目针对.NET 3.5或更高版本而导致编译器错误。

Microsoft.Core.Scripting.dll figured it out的作者，将“public”更改为“internal”。

namespace System.Runtime.CompilerServices
{
  internal sealed class ExtensionAttribute : Attribute { }
}

这似乎解决了VB兼容性问题。

因此，我可以信赖地将这种方法用于 widely-used ImageResizing.Net library的最新版本(3.2.1)。

但是 然后，对于某些面向.NET 3.5+的用户，我们开始或多或少随机地收到此编译器错误( original report)。

Error 5 Missing compiler required member
'System.Runtime.CompilerServices.ExtensionAttribute..ctor'

由于MSBuild/VisualStudio编译器显然在解决命名冲突时不会费心查看作用域规则，并且程序集引用的顺序起着不十分固定的作用，因此我不完全了解为什么以及何时发生这种情况。

有一个 few hacky workarounds，例如更改程序集 namespace ，重新创建项目文件，删除/读取System.Core以及摆弄.NET框架的目标版本。不幸的是，这些变通办法都不是100％(别名除外，但这是 Not Acceptable 痛苦)。

我如何在此期间解决此问题

维护对程序集

中扩展方法使用的支持

维护对.NET 2.0/3.0的支持

每个.NET Framework版本不需要多个程序集。

还是有修补程序使编译器注意作用域规则？

SO的相关问题，不能回答这个问题

C# Extension methods in .NET 2.0

Using Extension Methods with .NET Framework 2.0

strange warning about ExtensionAttribute

Ambigious reference for ExtensionAttribute when using Iron Python in Asp.Net

Should I support .NET 2.0?

Using extension methods in .NET 2.0?

Answer 1

我们在IronPython中遇到了同样的问题。 http://devhawk.net/2008/10/21/the-fifth-assembly/

我们最终将自定义版本的ExtensionAttribute移到其自己的程序集中。这样，客户可以在引用我们的自定义ExtensionAttribute程序集还是System.Core之间进行选择-但绝不能两者都选!

另一个棘手的事情是，即使您不在项目中引用它，也必须始终部署ExtensionAttribute程序集。您的公开扩展方法的项目程序集将具有对该自定义ExtensionAttribute程序集的assemblyref，因此，如果找不到CLR，它将感到不高兴。

鉴于对.NET 2.0支持的严格要求，我认为最好的选择是根本不使用扩展方法。我不熟悉ImageResizer项目，但听起来这是ImageResizer的最新更改。将扩展方法更改为传统的静态方法有多可行？我们实际上已经为IronPython/DLR考虑了这一点，但这是不可行的(当时我们与LINQ合并，并且LINQ实质上完全使用了扩展方法)。