“Рассматривайте все предупреждения как ошибки кроме …” в Visual Studio
8 ответов
Можно добавить WarningsNotAsErrors - отмечают на файле проекта.
<PropertyGroup>
...
...
<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>
Примечание: 612 и 618 оба предупреждения об Устаревшем, не знайте различие, но проект, я продолжаю работать, сообщает Устаревший с предупреждением 618.
или более конкретно, в Вашем случае:
/warnaserror/warnaserror-:612,1030,1701,1702
это должно рассматривать все предупреждения как ошибки за исключением тех в Вашем списке разделенных запятой значений
Почему Вы хотите продолжать видеть предупреждения, что Вы не рассматриваете как ошибки? Я смущен тем, почему это желательно - или Вы фиксируете их, или Вы не делаете.
Был бы два различных файла сборки/решения работать - или сценарий, чтобы скопировать один и затем так, чтобы изменить уровень предупреждений/предупреждения подойти. Кажется, что, возможно, Вы хотите, чтобы некоторое выполнение компилятора пронзительно кричало, но другие Вы хотите продолжать идти.
Так различные переключатели компилятора походит на хороший способ пойти. Вы могли сделать это с различными целями - одна маркированная отладка или выпуск и другие маркированные соответственно о предупреждениях.
Я использую предупреждения обработки в качестве ошибок.
В редкие случаи, когда некоторое приемлемое предупреждение обнаруживается (т.е. ссылка на устаревшего участника или недостающую документацию относительно классов сериализации XML), тогда это должно быть явно подавлено с #pragma, отключают (и дополнительно рассуждайте для того, чтобы не иметь чистый код, мог быть обеспечен как комментарий вперед).
Присутствие этой директивы также позволяет узнавать, , кто принял это нарушение предупреждения (действием "вины" управления версиями) в случае, если существуют некоторые вопросы.
прагма, предупреждающая (Ссылка C#)
прагма, предупреждающая, может использоваться, чтобы включить или отключить определенные предупреждения.
http://msdn.microsoft.com/en-us/library/441722ys (По сравнению с 80) .aspx
Это кажется мне, корневой проблемой является действительно комбинация Ваших предупреждений обработки как ошибки, когда они ясно не, и Ваша очевидная политика разрешения регистраций, которые нарушают это. Как Вы говорите, Вы хотите быть в состоянии продолжить работать несмотря на предупреждение. Вы только упомянули несколько предупреждений, которые Вы хотите быть в состоянии проигнорировать, но что, если бы кто-то еще в команде вызвал какой-либо другой тип предупреждения, которое брало бы Вас одинаково долго для фиксации? Разве Вы не хотели бы проигнорировать это также?
логичное решение должно было бы или 1) Запретить checkins, если код не компилирует (что означает, что те, кто создал предупреждения, должны будут зафиксировать их, с тех пор в действительности, они повредили сборку), или 2) предупреждения обработки как предупреждения. Создайте две конфигурации сборки, та, которая рассматривает предупреждения как ошибки, которые могут быть выполнены регулярно, чтобы гарантировать, что код без предупреждений, и другой, который только рассматривает их как предупреждения, и позволяет Вам работать, даже если кто-то еще представил предупреждение.