"Трактуйте всі попередження як помилки, за винятком ..." у 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 (і необов'язково, причину відсутності чистого коду можна надати як коментар разом).

Наявність цієї директиви також дозволяє з'ясувати, хто прийняв це попередження за порушення (шляхом дії "звинувачення" контролю версій) у випадку виникнення питань.

Чому б просто не було правила, що говорить: "Хто перевіряє код з будь-яким попередженням, що знаходиться всередині нього, крім 612, 1030, 1701 або 1702 в ньому, повинен зайти на дошку і написати сто разів", я не перевірятиму код із забороненими попередженнями знову. '"

попередження про прагму (C # Посилання)

для включення або вимкнення певних попереджень може використовуватися попередження прагми.

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

Мені здається, корінна проблема - це комбінація вашого трактування попереджень як помилок, коли їх явно немає, і вашої очевидної політики щодо дозволу на реєстрацію, що порушує це. Як ви кажете, ви хочете мати можливість продовжувати роботу, незважаючи на попередження. Ви згадали лише кілька попереджень, які ви хочете ігнорувати, але що робити, якщо хтось із команди викликав будь-який інший тип попередження, який би зайняв у вас однаково багато часу для виправлення? Чи не хочете ви також можете ігнорувати це?

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