Устаревший атрибут, зависящий от версии

#.net #attributes

#.net #атрибуты

Вопрос:

[Obsolete] Атрибут очень удобен для обозначения классов, которые были признаны устаревшими в пользу более совершенных реализаций, но он не зависит от версии .Net, на которую ориентирован проект.

Допустим, я использую развернутый ThreadSafeDictionary класс для версий .Net до 4.0. Когда вышел .Net 4.0, он включал новый класс под названием ConcurrentDictionary. Я хотел бы иметь возможность отмечать ThreadSafeDictionary как [Obsolete] , но только в том случае, если проект компилируется для .Net 4.0. Не похоже, что stock ObsoleteAttribute поддерживает управление предупреждениями компилятора в зависимости от версии платформы.

Есть ли какой-либо способ сделать это?

1. Возможно, это педантично, но если метод устарел, он устарел во всех версиях — если вы компилируете для 2.0, он все еще устарел на самом деле! (Они должны обновиться, чтобы получить доступ к более подходящему классу)

2. Я не всегда могу обновить каждую программу до самой последней версии. Например, у нас есть платформа промежуточного программного обеспечения, которая должна пройти тщательный контроль качества, прежде чем ее сертифицируют для использования последней версии фреймворка. Тем временем мы должны иметь возможность развертывания на .Net 3.5 при разработке новых проектов / ветвей, которые в конечном итоге будут развернуты на 4.0

3. Лоуренс: Это не значит, что он не устарел; часто бывает так, что мы вынуждены использовать устаревшую версию. Я работаю с платформой электронной коммерции ATG, и она была сертифицирована для работы на Java 1.6 только более чем через год после того, как срок службы Java 1.5 Sun истек. Сумасшедшие времена.

Ответ №1:

Я думаю, вы могли бы развернуть свой пользовательский атрибут, а затем создать процесс после сборки, который проверяет скомпилированный код посредством рефлексивного поиска вашего атрибута.