Создайте атрибут, чтобы сломать сборку

Question

ОК, этот вид следует из моего предыдущего вопроса .

Что я действительно хотел бы сделать, так это создать какой-то атрибут, который позволит мне декорировать метод, который нарушит сборку . Очень похоже на устаревший («причина», истина) атрибут, но без ложной идентификации устаревшего кода.

Чтобы уточнить : я не хочу, чтобы он ломал сборку на ЛЮБОМ F6 (Build) прессе, я хочу, чтобы он ломал сборку только если метод, украшенный атрибутом вызывается где-то еще в коде. Как я уже сказал, похоже на устаревшее, но не то же самое.

Я знаю, что я не одинок в этом, поскольку другие пользователи хотят использовать его по другим причинам . Я никогда раньше не создавал пользовательских атрибутов, поэтому для меня это все ново!

Answer 1

Я думаю, что это был бы отличный запрос для Microsoft: создайте абстрактный атрибут базового класса CompilerExecutedAttribute, который компилятор каким-то образом обрабатывает или может повлиять на процесс компиляции. Тогда мы могли бы наследовать от этого атрибута и реализовывать различные операции, например, выдать ошибку или предупреждение.

Answer 2

Если это для сериализации XML и NHibernate, где вы хотите, чтобы конструктор без параметров был доступен (как в случае примера , на который вы ссылались), тогда используйте частный или защищенный конструктор без параметров для сериализации или защищенный конструктор для NHibernate. С защищенной версией вы открываете себя для унаследованных классов, способных вызывать этот код.

Если вы не хотите, чтобы код вызывал метод, не делайте его доступным.

РЕДАКТИРОВАТЬ: Чтобы, возможно, ответить на более глубокий вопрос, AFAIK компилятор знает только о трех атрибутах: Устаревшие, Условные и AttributeUsage . Чтобы добавить специальную обработку для других атрибутов, потребуется изменить компилятор.

Answer 3

Если вы считаете, что предупреждение (которое выдает [устаревший]) нарушает сборку, то просто используйте директиву компилятора # warning .

Изменить: я никогда не использовал его, но # ошибка также доступна.

Answer 4

Я думаю, что единственный надежный способ - это расширить Visual Studio (через VSIP) и подписаться на правильный класс события (возможно, в EnvDTE.BuildEvents), проверить ваш код на использование конструктора и отменить построить, если вы обнаружите это.

Answer 5

Отвечая 4 года спустя :)

У меня был такой же вопрос, была ли альтернатива устаревшей.

Из того, что я помню (видео 9-го канала), Microsoft заявляла, что в какой-то момент она работает над тем, чтобы дать разработчикам доступ к чему-то вроде API компилятора, поэтому в будущем вполне возможно, что вы сможете написать «плагин» компилятора, который позволит декорировать методы с помощью вашего собственного пользовательского атрибута и сказать компилятору отменить, если он выглядит так, как будто декорированный код может вызываться где-то еще в коде и т. д.

Что на самом деле было бы круто, если подумать. Это также напоминает мне, что я должен также попытаться прочитать о том, как работает API компилятора, над которым работает MS ...

Answer 6

Создание пользовательского исключения и модульного теста для него в качестве шага после сборки

Answer 7

Создайте правило FxCop и добавьте FxCop в сборку интеграции, чтобы проверить это.

Вы получите предупреждения, а не неудачную сборку. Атрибуты «запускаются» во время отражения, а не во время сборки.

В качестве альтернативы (и это довольно неприятно) поместите директиву компилятора вокруг метода, который вы не хотите вызывать. Тогда ваш код сломается, если вы его вызовите, но вы можете настроить сборку, которая передает правильную директиву компилятора, а не.

Answer 8

Я бы предложил вам использовать директиву #error.

Другим довольно неизвестным атрибутом, который может выполнять эту работу, является условный атрибут (в зависимости от того, что вы пытаетесь достичь)

[Conditional("CONDITION")] 
public static void MiMethod(int a, string msg)

, который удалит вызов метода из самого кода IL, если определено «MY_CONDITION».

Answer 9

Я должен согласиться с Грегом: придумать для него атрибут.

А если вы действительно серьезны, возможно, найдите способ выяснить, к чему конструктор обращается, кроме XMLSerializer, и сгенерировать исключение, если оно есть.

Answer 10

Почему бы просто не придумать что-нибудь? Неизвестный атрибут наверняка сломает сборку.

[MyMadeUpAttributeThatBreaksTheBuildForSure]
public class NotDoneYet {}