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 .
Но , затем , мы начинаем получать эту ошибку компилятора(исходный отчет), более или менее случайно, для определенных пользователей, ориентированных на.NET 3.5+.
Error 5 Missing compiler required member
'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Поскольку компилятор MSBuild/VisualStudio, по-видимому, не удосуживается посмотреть на правила области видимости при разрешении конфликтов имен, а порядок ссылок на сборки играет не -вполне -задокументированную роль, я не совсем понимаю, почему и когда это бывает.
Существует несколько хакерских обходных путей , таких как изменение пространства имен сборки, воссоздание файла проекта, удаление/чтение System.Core и изменение целевой версии.NET Framework. К сожалению, ни один из этих обходных путей не является стопроцентным (, за исключением алиасинга, но это неприемлемая боль ).
Как я могу это исправить, пока
- Сохранение поддержки использования метода расширения в сборке,
- Сохранение поддержки.NET 2.0/3.0
- Не требуется несколько сборок для каждой версии.NET Framework.
Или есть исправление, чтобы компилятор обращал внимание на правила области видимости?
Связанные вопросы по SO, которые не отвечают на этот вопрос