"Обработать все предупреждения как ошибки, кроме..." в Visual Studio

В Visual Studio я могу выбрать опцию "Обрабатывать предупреждения как ошибки", чтобы предотвратить компиляцию моего кода, если есть какие-либо предупреждения. Наша команда использует эту опцию, но есть два предупреждения, которые мы хотели бы сохранить как предупреждения.

Существует возможность подавления предупреждений, но мы действительно хотим, чтобы они отображались как предупреждения, чтобы это не сработало.

Похоже, что единственный способ получить желаемое поведение - это ввести список каждого номера предупреждения С# в текстовое поле "Особые предупреждения", за исключением двух, которые мы хотим рассматривать как предупреждения.

Помимо головной боли при обслуживании, самым большим недостатком этого подхода является то, что в нескольких предупреждениях нет цифр, поэтому на них нельзя ссылаться в явном виде. Например, "Не удалось разрешить эту ссылку. Не удалось найти сборку" Данные.... ""

Кто-нибудь знает лучший способ сделать это?

Разъяснение для тех, кто не сразу видит, почему это полезно. Подумайте, как работает большинство предупреждений. Они говорят вам, что что-то не так в коде, который вы только что написали. Их исправление занимает около 10 секунд, и это обеспечивает чистоту базы кода.

"Устаревшее" предупреждение сильно отличается от этого. Иногда исправление означает просто использование новой сигнатуры метода. Но если весь класс устарел и его использование разбросано по сотням тысяч строк кода, исправление может занять несколько недель или даже больше. Вы не хотите, чтобы сборка была сломана так долго, но вы определенно хотите увидеть предупреждение об этом. Это не просто гипотетический случай - это случилось с нами.

Буквальные "#warning" предупреждения также уникальны. Я часто хочу проверить это, но не хочу ломать сборку.

Ответ 1

Вы можете добавить WarningsNotAsErrors -tag в файл проекта.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Примечание: 612 и 618 - оба предупреждения об устаревших, не знаю разницы, но проект, над которым я работаю, сообщает об устаревших с предупреждением 618.

Ответ 2

/warnaserror/warnaserror-: 618

Ответ 3

или, более конкретно, в вашем случае:

/warnaserror/warnaserror-: 612,1030,1701,1702

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

Ответ 4

Почему вы хотите видеть предупреждения, которые вы не рассматриваете как ошибки? Я смущен, почему это желательно - либо вы их исправляете, либо нет.

Будет ли работать два разных файла сборки/решения - или script, чтобы скопировать один, а затем измените уровень предупреждений/предупреждений. Кажется, что, возможно, вы хотите, чтобы некоторые исполнения компилятора сквозили, а другие вы хотите продолжать.

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

Ответ 5

Я использую предупреждения обработки как ошибки.

В редких случаях, когда появляется какое-то приемлемое предупреждение (например, ссылка на устаревший член или отсутствующая документация по классам сериализации XML), тогда он должен быть явно подавлен С#pragma disable (и необязательно причина отсутствия чистого кода может быть предоставлена в виде комментария).

Присутствие этой директивы также позволяет узнать, кто принял это предупреждение (посредством действия "вины" контроля версий) в случае возникновения некоторых вопросов.

Ответ 6

Почему бы просто не ввести правило, в котором говорилось: "Кто бы ни проверял код с каким-либо предупреждением внутри него, кроме 612, 1030, 1701 или 1702, он должен перейти на доску и написать сто раз." Я не буду проверять код с запрещенным предупреждения снова. "

Ответ 7

предупреждение pragma (ссылка С#)

Предупреждение pragma может использоваться для включения или отключения определенных предупреждений.

http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx

Ответ 8

Мне кажется, что проблема с корнем - это комбинация ваших предупреждений о предупреждениях, когда они явно не являются, и ваша очевидная политика разрешений на регистрацию, которые нарушают это. Как вы говорите, вы хотите продолжить работу, несмотря на предупреждение. Вы упомянули только несколько предупреждений, которые вы хотите игнорировать, но что, если кто-то из команды вызвал какой-либо другой тип предупреждения, что потребовало бы вас в равной степени долго исправлять? Не хотите ли вы также игнорировать это?

Логическое решение будет состоять в том, чтобы либо 1) Disallow checkins, если код не компилируется (это означает, что те, кто создал предупреждения, должны будут их исправить, поскольку фактически они нарушили сборку) или 2) обрабатывают предупреждения как предупреждения. Создайте две конфигурации сборки, которые обрабатывают предупреждения как ошибки, которые можно запускать регулярно, чтобы гарантировать, что код не содержит предупреждений, а другой, который относится только к ним как предупреждения, и позволяет вам работать, даже если кто-то еще представил предупреждение.