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

Question

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

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

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

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

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

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

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

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

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

716 8

c#visual-studio-2008 msbuild

8 ответов:

Comments

Ничего не найдено.

SvenL · Accepted Answer · 2014-03-17 08:53:37

вы можете добавить WarningsNotAsErrors-тег в файле проекта.
<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>
Примечание: 612 и 618 оба предупреждения об устаревших, не знаю разницы, но проект, над которым я работаю, сообщает об устаревании с предупреждением 618.

score 11 · Accepted Answer · 2008-12-19 10:51:03

/warnaserror /warnaserror-:618

11

2008-12-19 10:51:03

score 3 · Accepted Answer · 2008-12-19 10:53:32

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

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

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

Tim · Accepted Answer · 2008-11-06 04:21:25

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

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

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

Rinat Abdullin · Accepted Answer · 2009-01-22 08:31:36

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

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

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

erikkallen · Accepted Answer · 2009-09-30 19:45:46

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

Jay Bazuzi · Accepted Answer · 2009-01-22 08:43:40

pragma warning (C# Reference)

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

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

jalf · Accepted Answer · 2008-11-10 20:22:31

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

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