Ucieczka Paragraf 22 z rozszerzeniem atrybutów w .NET 2.0

Question

jaki sposób pojedynczy zespół .NET kierowania 2,0, 3,0, 3,5, 4,0, 4,5 Jednocześnie metody rozszerzenie wsparcia zarówno dla C# i VB.NET konsumentów?

Standardowa propozycja jest taka, aby dodać to:

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

To podejście sugerowane przez more niż one Microsoft employee i została nawet wyróżniona w MSDN magazine. To widely okrzyknięty przez many bloggers jako posiadające "brak niepokojących objawów.

Och, z wyjątkiem spowoduje to błąd kompilatora z projektu VB.NET kierowania .NET 3.5 lub wyższa.

Autorzy Microsoft.Core.Scripting.dll figured it out i zmienił „publicznego” na „wewnętrzną”.

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

Co wydawało się rozwiązać problem zgodności VB.

więc ufnie stosować takie podejście do najnowszej wersji (3.2.1) z widely-used ImageResizing.Net library.

Ale następnie, zaczynamy coraz ten błąd kompilatora (original report), mniej lub bardziej losowo, dla niektórych użytkowników kierowanych na .NET 3.5+.

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

Ponieważ MSBuild/VisualStudio kompilator najwyraźniej nie przeszkadza, aby spojrzeć na zasady dotyczące zakresu podczas rozwiązywania konfliktów nazw, a kolejność odniesienia montażowych odgrywa nie-całkiem-docuemented rolę, nie w pełni zrozumieć, dlaczego i kiedy to się dzieje.

Istnieje few hacky workarounds, takich jak zmiana obszaru nazw zespołu, odtworzenie pliku projektu, usunięcie/odczytanie SystemCore i manipulowanie docelową wersją platformy .NET. Niestety, żadne z tych obejść nie są w 100% (z wyjątkiem aliasingu, ale jest to niedopuszczalny ból).

Jak mogę rozwiązać ten problem podczas

1. Utrzymanie poparcia dla rozszerzenia stosowania metody w zespole,
2. Utrzymanie wsparcia dla .NET 2.0/3.0
3. nie wymagające wielu zestawów dla każdej wersji .NET Framework .

Czy jest tam poprawka, aby kompilator zwrócił uwagę na reguły dotyczące zakresu?

Powiązane pytania dotyczące tak, że nie odpowie na to pytanie

• 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

Napotkaliśmy na ten sam problem z IronPython. http://devhawk.net/2008/10/21/the-fifth-assembly/

Zakończyliśmy przenoszenie naszej niestandardowej wersji ExtensionAttribute do własnego zestawu. W ten sposób klienci mogą wybierać między odwoływaniem się do naszego niestandardowego zestawu ExtensionAttribute lub System.Core - ale nigdy do obu!

Inną trudną rzeczą jest to, że zawsze należy wdrożyć zestaw ExtensionAttribute - nawet jeśli nie odwołujesz się do niego w projekcie. Zespoły projektu, które eksponują metody rozszerzeń, będą miały odwołanie assemblyref do tego niestandardowego zestawu ExtensionAttribute, więc CLR będzie denerwować się, jeśli nie można go znaleźć.

Biorąc pod uwagę twarde wymagania obsługi .NET 2.0, uważam, że najlepiej byłoby po prostu nie stosować w ogóle metod rozszerzania. Nie jestem zaznajomiony z projektem ImageResizer, ale wygląda na to, że była to ostatnia zmiana w ImageResizer. Jak można zmienić metody rozszerzania na tradycyjne metody statyczne? Myśleliśmy o tym w IronPython/DLR, ale nie było to wykonalne (w tym momencie połączono nas z LINQ, a LINQ intensywnie korzystał z metod rozszerzenia w zasadzie dla całego swojego istnienia).