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

Question

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

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

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

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

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

---

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

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

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

Answer 1

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

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

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

Answer 2

/ warnaserror / warnaserror-: 618

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

предупреждение о прагме (C # Reference)

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

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

Answer 8

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

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