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

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

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

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

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

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

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

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

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

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

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

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

/ warnaserror / warnaserror-: 618

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

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

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

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

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

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

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

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

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

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

предупреждение прагмы (Справочник по C #)

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

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

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

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