Escape Catch-22 с атрибутами расширения в .NET 2.0

Как может одна сборка .NET, ориентированная одновременно на версии 2.0, 3.0, 3.5, 4.0 и 4.5, поддерживать методы расширения для потребителей C # и VB.NET?

Стандартное предложение - добавить следующее:

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

Этот подход предложен подробнее чем один сотрудник Microsoft и даже был представлен в журнал MSDN. Это широко приветствуется у многих блоггеров как« без вредных последствий ».

О, за исключением того, что это вызовет ошибку компилятора из проекта VB.NET, ориентированного на .NET 3.5 или выше.

Разобрались авторы Microsoft.Core.Scripting.dll и изменил "общедоступный" на "внутренний".

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

Что, казалось, решило проблему совместимости с VB.

Поэтому я с доверием использовал этот подход для последней версии (3.2.1) широко используемой библиотеки ImageResizing.Net.

Но тогда мы начинаем получать эту ошибку компилятора (исходный report), более или менее случайно, для определенных пользователей, ориентированных на .NET 3.5+.

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

Поскольку компилятор MSBuild / VisualStudio, очевидно, не заботится о правилах определения области видимости при разрешении конфликтов имен, а порядок ссылок на сборки играет не совсем документированную роль, я не совсем понимаю, почему и когда это происходит.

Есть несколько хитрых обходных решений, таких как изменение пространства имен сборки, воссоздание файла проекта, удаление / чтение System.Core и возиться с целевой версией .NET framework. К сожалению, ни один из этих обходных путей не является стопроцентным (кроме псевдонима, но это недопустимая боль).

Как я могу это исправить, пока

  1. Поддержка использования метода расширения в сборке,
  2. Поддержка .NET 2.0 / 3.0
  3. Не требуется несколько сборок для каждой версии .NET framework.

Или есть исправление, чтобы компилятор обращал внимание на правила области видимости?

Связанные вопросы по SO, которые не отвечают на этот вопрос


clr extension-methods vbc csc
person Lilith River    schedule 14.06.2012    source источник
comment
Фу. В вашей награде отсутствует ноль. Лучше всего обсудить это с службой поддержки Microsoft, хотя они, скорее всего, отклонят это со словом «не поддерживается».   -  person Hans Passant    schedule 19.06.2012

Ответы (1)


arrow_upward
2
arrow_downward

Мы столкнулись с той же проблемой с IronPython. http://devhawk.net/2008/10/21/the-fifth-assembly/

В итоге мы переместили нашу пользовательскую версию ExtensionAttribute в его собственную сборку. Таким образом, клиенты могли выбирать между ссылкой на нашу настраиваемую сборку ExtensionAttribute или System.Core - но не на оба сразу!

Другая сложность заключается в том, что вам нужно всегда развертывать сборку ExtensionAttribute, даже если вы не ссылаетесь на нее в своем проекте. Сборки вашего проекта, которые предоставляют методы расширения, будут иметь ссылку на сборку для этой настраиваемой сборки ExtensionAttribute, поэтому среда CLR расстроится, если ее не удастся найти.

Учитывая жесткое требование поддержки .NET 2.0, я считаю, что лучше всего вообще не использовать методы расширения. Я не знаком с проектом ImageResizer, но похоже, что это было недавнее изменение в ImageResizer. Насколько возможно изменить методы расширения на традиционные статические методы? Мы действительно думали об этом для IronPython / DLR, но это было невозможно (на тот момент мы были объединены с LINQ, и LINQ широко использовал методы расширения на протяжении всего своего существования).

person DevHawk    schedule 20.06.2012
comment
Спасибо, что обновили статью ссылкой! Я думаю, Newtonsoft.Json столкнулся с тем же кошмаром, что и мы ... Слишком много блогов говорят, что нет никаких последствий, и когда я прочитал тот же факт, неоспоримый в полдюжине блогов, я предположил, что это правда! - person Lilith River; 20.06.2012
comment
Просто идея, можно ли как-нибудь обойтись с переадресацией типов? - person Pavel Savara; 21.06.2012
comment
К вашему сведению, я добавил в свой блог расширенное объяснение: devhawk.net/2012/ 20 июня / ambiguous-extensionattribute-errors - person DevHawk; 08.09.2012
comment
Обновлены ссылки на те, которые упомянуты @DevHawk devhawk.net/blog/2008/ 21 октября / пятая сборка devhawk.net / blog / 2012/6/21 / ambiguous-extensionattribute-errors - person MarkP; 03.07.2019