Visual studio уровень ошибок

Обновлено: 07.07.2024

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

Настройка уровней серьезности

начиная с Visual Studio 2019 версии 16,3, можно настроить уровень серьезности правил анализатора или диагностики в EditorConfig-файле, из меню лампочкии из списка ошибок.

при установке анализаторов в качестве пакета NuGet можно настроить серьезность правил анализатора или диагностики. Серьезность правила можно изменить с Обозреватель решений или в файле набора правил.

В следующей таблице показаны различные параметры серьезности.

Если анализатор обнаруживает нарушения правил, они помечаются в редакторе кода (волнистая линия под соответствующим кодом) и в окне "Список ошибок".

Нарушения анализаторов, приведенные в списке ошибок, соответствуют уровню серьезности правила. Нарушения анализаторов выделяются в редакторе кода с помощью волнистых линий под соответствующим кодом. На следующем рисунке показаны три нарушения — одна ошибка (красная волнистая линия), одно предупреждение (зеленая волнистая линия) и одно предложение (три серые точки):

Волнистые линии в редакторе кода в Visual Studio

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

Ошибка, предупреждение и нарушение сведений в список ошибок

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

Нарушение анализа и исправление кода быстрого действия

"Hidden" серьезность и серьезность "нет"

Hidden правила серьезности, включенные по умолчанию, отличаются от правил "отключено" или " None серьезность" несколькими способами.

Задание серьезности правила в файле EditorConfig

(Visual Studio 2019 версии 16,3 и более поздних версий)

Можно задать серьезность предупреждений компилятора или правил анализатора в файле EditorConfig с помощью следующего синтаксиса:

dotnet_diagnostic.<rule ID>.severity = <severity>

Настройка степени серьезности правила в файле EditorConfig имеет приоритет над любым уровнем серьезности, установленным в наборе правил или в обозреватель решений. Можно вручную настроить серьезность в файле EditorConfig или автоматически с помощью лампочки, отображаемой рядом с нарушением.

Задание серьезности правила с несколькими анализаторами одновременно в файле EditorConfig

(Visual Studio 2019 версии 16,5 и более поздних версий)

Можно задать уровень серьезности для определенной категории правил анализатора или для всех правил анализатора с одной записью в файле EditorConfig.

  • Задайте серьезность правила для категории правил анализатора:

dotnet_analyzer_diagnostic.category-<rule category>.severity = <severity>

  • Задать серьезность правила для всех правил анализатора:

Записи для настройки нескольких правил анализатора одновременно применяются только к правилам, включенным по умолчанию. Правила анализатора, отмеченные как отключенные по умолчанию в пакете анализатора, должны быть включены через явные dotnet_diagnostic.<rule ID>.severity = <severity> записи.

При наличии нескольких записей, применимых к определенному ИДЕНТИФИКАТОРу правила, для выбора применимой записи используется следующий порядок приоритета:

  • Запись серьезности для отдельного правила по ИДЕНТИФИКАТОРу имеет приоритет над записью степени серьезности для категории.
  • Запись серьезности для категории имеет приоритет над записью степени серьезности для всех правил анализатора.

Рассмотрим следующий пример EditorConfig, где CA1822 имеет категорию "производительность":

В предыдущем примере все три записи применимы к CA1822. Однако при использовании указанных правил приоритета запись с уровнем серьезности на основе идентификатора правила WINS передается на следующие записи. В этом примере CA1822 будет иметь действительную серьезность "ошибка". Все остальные правила с категорией "производительность" будут иметь серьезность "предупреждение". Все оставшиеся правила анализатора, у которых нет категории "производительность", будут иметь серьезность "предложение".

Настройка важности правила вручную в файле EditorConfig

Если у вас еще нет файла EditorConfig для проекта, добавьте его.

Для анализаторов кода интегрированной среды разработки можно также настроить их в файле EditorConfig, используя другой синтаксис, например dotnet_style_qualification_for_field = false:suggestion . Однако если задать серьезность с помощью dotnet_diagnostic синтаксиса, он имеет приоритет. Дополнительные сведения см. в разделе языковые соглашения для EditorConfig.

Установка серьезности правила из меню лампочки

Visual Studio предоставляет удобный способ настройки серьезности правила из меню лампочки быстрые действия .

После возникновения нарушения наведите указатель мыши на нарушение в редакторе и откройте меню лампочки. Или наведите курсор на строку и нажмите клавишу CTRL + . (точка).

В меню лампочки выберите Настройка или отключение проблем > Настройка <rule ID> серьезности.

Настройка серьезности правила из меню лампочки в Visual Studio

В нем выберите один из вариантов серьезности.

Настройка серьезности правила в качестве предложения

Visual Studio добавляет запись в файл EditorConfig, чтобы настроить правило на запрошенном уровне, как показано в поле предварительного просмотра.

если в проекте еще нет файла EditorConfig, Visual Studio создаст его.

Задание серьезности правила в окне список ошибок

Visual Studio также предоставляет удобный способ настройки серьезности правила из контекстного меню списка ошибок.

После возникновения нарушения щелкните правой кнопкой мыши запись диагностики в списке ошибок.

В контекстном меню выберите задать серьезность.

Настройка серьезности правила из списка ошибок в Visual Studio

В нем выберите один из вариантов серьезности.

Visual Studio добавляет запись в файл EditorConfig, чтобы настроить правило на запрошенном уровне.

если в проекте еще нет файла EditorConfig, Visual Studio создаст его.

Установка серьезности правила с обозреватель решений

Большую часть настройки диагностики анализатора можно выполнить из Обозреватель решений. если анализаторы устанавливаются в виде пакета NuGet, узел анализаторов отображается в узле ссылки или зависимости в обозреватель решений. Если развернуть анализаторы, а затем развернуть одну из сборок анализатора, отобразятся все диагностические сведения в сборке.

Узел «Анализаторы» в обозреватель решений

Свойства диагностики, включая ее описание и серьезность по умолчанию, можно просмотреть в окне Свойства . Чтобы просмотреть свойства, щелкните правило правой кнопкой мыши и выберите пункт Свойства или выберите правило, а затем нажмите клавишу ALT + Ввод.

Свойства диагностики в окно свойств

Чтобы просмотреть электронную документацию по диагностике, щелкните правой кнопкой мыши диагностику и выберите команду просмотреть справку.

Значки рядом с каждой диагностикой в Обозреватель решений соответствуют значкам, отображаемым в наборе правил при его открытии в редакторе:

  • "x" в окружности обозначает серьезностьошибки
  • знак "!" в треугольнике указывает на серьезностьпредупреждения
  • "i" в окружности обозначает серьезностьинформации
  • «i» в круге на светло-цветном фоне указывает на серьезностьскрытого
  • направленная вниз стрелка в окружности означает, что диагностика подавлена

Преобразование существующего файла набора правил в файл EditorConfig

начиная с Visual Studio 2019 версии 16,5, файлы ruleset не рекомендуются в пользу файла EditorConfig для настройки анализатора для управляемого кода. большая часть Visual Studio средств для настройки серьезности правил анализатора была обновлена для работы с файлами EditorConfig, а не файлами правил. файлы EditorConfig позволяют настраивать серьезность правил и параметры анализатора, включая Visual Studio параметры стиля кода IDE. Настоятельно рекомендуется преобразовать существующий RuleSet-файл в файл EditorConfig. Также рекомендуется сохранить файл EditorConfig в корне репозитория или в папке решения. Используя корневой каталог репозитория или папки решения, вы убедитесь, что параметры серьезности из этого файла автоматически применяются ко всему репозиторию или решению соответственно.

Существует несколько способов преобразования существующего RuleSet-файла в файл EditorConfig:

в редакторе набора правил в Visual Studio (требуется Visual Studio 2019 16,5 или более поздней версии). Если в проекте уже используется конкретный файл RuleSet CodeAnalysisRuleSet , его можно преобразовать в эквивалентный файл EditorConfig из редактора набора правил в Visual Studio.

Дважды щелкните файл RuleSet в обозреватель решений.

Файл набора правил должен быть открыт в редакторе набора правил. В верхней части редактора набора правил должна отобразиться отображаемая информационная панель .

Преобразование набора правил в файл EditorConfig в редакторе набора правил

Щелкните ссылку на информационную панель .

Откроется диалоговое окно Сохранить как , в котором можно выбрать каталог, в котором нужно создать файл EditorConfig.

Созданный EditorConfig должен быть открыт в редакторе. кроме того, свойство MSBuild CodeAnalysisRuleSet обновляется в файле проекта, чтобы он больше не ссылался на исходный файл ruleset.

Из командной строки.

Выполните RulesetToEditorconfigConverter.exe из установленного пакета с путями к файлу набора правил и файлом EditorConfig в качестве аргументов командной строки.

Ниже приведен пример RuleSet-файла для преобразования:

Ниже приведен преобразованный файл EditorConfig:

Установка серьезности правила с обозреватель решений

Разверните сборку, содержащую правило, для которого нужно задать серьезность.

Щелкните правило правой кнопкой мыши и выберите пункт задать серьезность. В контекстном меню выберите один из параметров серьезности.

Visual Studio добавляет запись в файл EditorConfig, чтобы настроить правило на запрошенном уровне. Если в проекте используется файл набора правил вместо EditorConfig-файла, запись о серьезности добавляется в RuleSet-файл.

если в проекте еще нет файла EditorConfig или ruleset, Visual Studio создает новый файл EditorConfig.

Щелкните правило правой кнопкой мыши и выберите пункт задать серьезность набора правил. В контекстном меню выберите один из параметров серьезности.

Уровень серьезности для правила сохраняется в файле активного набора правил.

Задание серьезности правила в файле набора правил

Файл набора правил в обозреватель решений

  1. Откройте активный файл набора правил одним из следующих способов:

В Обозреватель решений дважды щелкните файл, щелкните правой кнопкой мыши узел > анализаторы ссылок и выберите команду Открыть активный набор правил.

на странице свойств Code Analysis проекта выберите открыть .

если вы изменяете набор правил в первый раз, Visual Studio создает копию файла набора правил по умолчанию, присваивает ему имя <projectname> . ruleset и добавляет его в проект. Этот настраиваемый набор правил также станет активным набором правил для вашего проекта.

Перейдите к правилу, развернув его содержащую его сборку.

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

Файл набора правил открыт в редакторе

Настройка созданного кода

Анализаторы выполняются на всех исходных файлах в проекте и сообщают о нарушениях на них. Однако эти нарушения не применяются к созданным файлам кода, таким как файлы кода, созданные конструктором, временные исходные файлы, созданные системой сборки и т. д. Пользователи не могут вручную изменять эти файлы и (или) не беспокоиться об устранении нарушений в таких файлах, созданных с помощью инструментария.

По умолчанию драйвер анализатора, который выполняет анализаторы, обрабатывает файлы с определенным именем, расширением или автоматически созданным заголовком файла в виде созданных файлов кода. Например, файл с постфиксом .designer.cs или .generated.cs считается содержащим созданный код. Однако эти эвристики могут не иметь возможности определять все пользовательские файлы кода, созданные в исходном коде пользователя.

начиная с Visual Studio 2019 16,5, конечные пользователи могут настраивать определенные файлы и (или) папки для обработки в виде сформированного кода в файле EditorConfig. Чтобы добавить такую конфигурацию, выполните следующие действия.

Если у вас еще нет файла EditorConfig для проекта, добавьте его.

Добавление generated_code = true | false записи для конкретных файлов и папок. Например, чтобы обрабатывать все файлы, имена которых заканчиваются на .MyGenerated.cs сформированном коде, запись будет выглядеть следующим образом:

Подавлять нарушения

Нарушения правил можно подавлять с помощью различных методов. Дополнительные сведения см. в разделе подавлять нарушения анализа кода.

Использование командной строки

При сборке проекта в командной строке нарушения правил появляются в выходных данных сборки, если выполняются следующие условия.

В коде проекта нарушается одно или несколько правил.

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

Уровень детализации выходных данных сборки не влияет на отображение нарушений правил. Даже при неавтоматическом уровне детализации нарушения правил появляются в выходных данных сборки.

Если вы привыкли выполнять анализ прежних версий из командной строки с помощью FxCopCmd.exe или с помощью MSBuild с флагом рункодеаналисис , это можно сделать с помощью анализаторов кода.

Чтобы просмотреть нарушения анализатора в командной строке при сборке проекта с помощью MSBuild, выполните следующую команду:

На следующем изображении показаны выходные данные сборки из командной строки для создания проекта, содержащего нарушение правила анализа:

Выходные данные MSBuild с нарушением правила

Зависимые проекты

FAIL

Обычная ситуация: вы написали кусок безупречно правильного кода, но Visual C++ выдает на нем предупреждение. Часто можно немного переписать код, чтобы предупреждение ушло, но не всегда, и тогда выход один – глушить выдачу этого предупреждения.

Рассмотрим, какие возможности для этого есть в Visual C++ и какие ошибки допускают при их использовании.

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

… и остаются очень довольны собой. Предупреждение заглушили, код написали, предупреждение восстановили. Прибыль.

1. устанавливает предупреждению уровень по умолчанию и
2. включает предупреждение.

Сначала уровни. В Visual C++ с каждым предупреждением связано число от 1 до 4 – это уровень предупреждения. Предупреждения уровня 1 считаются более серьезными, с ростом уровня серьезность якобы снижается. У каждого предупреждения есть уровень по умолчанию. Конструкция

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

У компилятора есть настройка, с какого уровня предупреждения показывать, Warning Level. При значении этой настройки, равном A, предупреждение в конкретной строке кода показывается только в том случае, если оно там разрешено и его уровень составляет A или ниже.

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

Зачем он это делает, если предупреждение и так выключено? Список предупреждений, выключенных по умолчанию, меняется от одной версии Visual C++ к другой – в него понемногу добавляются предупреждения. Если код изначально писали для Visual C++ 7, а там C9001 по умолчанию было включено, а теперь компилируют в Visual C++ 10, и в нем предупреждение уже выключено, то такая конструкция смысла не имеет, а могла просто достаться в наследство.

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

На самом деле, предупреждения нужно глушить так:

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

Выглядит страшно, но чего не сделаешь, чтобы не пропустить ту самую ошибку на миллиард.

В новом чистом проекте 5 ошибок без текста
Установил я самую последнюю версию unity и мне уже не впервой выдает 5 неизвестных ошибок в чистом.

Полоса в новом проекте
Только что установил XNA. Испортить сам ещё ничего не успел. Запускаю новый проект и сразу.

Ошибки в новом проекте (Eclipse)
Error retrieving parent for item: No resource found that matches the given name.

Включить dep в новом проекте
как включить dep в новом проекте? использую visual studio 2010 express

А какие именно компоненты ?
Window 10 SDK ?
Universal CRT?

И что там в созданном проекте ?

Решение

решил писать на C++, скачал VS, установил компонеты, создаю проект и получаю 400+ ошибок. Что делать? В настройках проекта нужно выбрать установленный проект SDK (у Вас установлен 10.0.17763.0).
Меню
Проект -> Свойства ->Свойства конфигурации->Версия пакета SDK.


Eclipse в новом проекте не создает MainActivity
Привык, что при создании проекта в эклипс мгновенно создается активити, а теперь - нет. Каталог src.

Nunit фреймворк. Использование в новом проекте
Подскажите, необходимо каждый раз по новой скачивать NUnit фреймворк для нового проекта? Или я что.


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

Для желающих принять участие в новом проекте (тестовый режим - в июле).
В стадии запуска интернет-проект‚ связанный с развитием новых видеосервисов. Контент для портала.


В новом проекте двойной клик по Label пишет текст метки в буфер обмена
Здрасьте! Когда два раза кликаю на кнопку он копирует текст из label почему? Как можно это.


В новом проекте двойной клик по Label пишет текст метки в буфер обмена
Создаю пустой проект winform, кидаю на форму компонент label1, запускаю. при двойном клике по.

Lorem ipsum dolor

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

Отладка кода — это один из самых важных процессов. Без отладки в свет не выходит ни одно нормальное приложение. Потому что , независимо от опыта разработчика, код не всегда работает так , как нужно. А иногда и вообще работает совершенно не так. Вот тут как раз и приходит на помощь отладчик, который позволит разобраться , что не так , и найти изъяны. Можно , конечно , много часов провести за самостоятельным выявлением багов, но отладчиком все-таки быстрее и проще.

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

Работа с отладчиком , даже с таким простым , как Visual Studio, требует определенных знаний и понимания , что там внутри происходит. Умение работать с отладчиком вам в любом случае пригодится, если вы хотите связать свою жизнь с разработкой ПО. В этой статье мы ознакомим вас с процессом отладки при помощи Visual Studio.

Отладка кода в Visual Studio

  • орфографические ошибки или опечатки,
  • неправильно подключенные API,
  • неправильное размещение последних корректировок в код,
  • и др.
  • ошибка компиляции;
  • ошибка преобразования типа;
  • код не поддерживает синтаксис;
  • и др .

Как запустить отладчик Visual Studio

  1. Запустить саму программу Visual Studio.
  2. Откр ыть код приложения, который необходимо отладить.
  3. Потом при помощи нажатия клавиши «F5» запустить режим отладки. Также это можно сделать через меню, если нажать «Отладка», а потом «Начать отладку» .
  • последовательность исполнения кода;

  • работу памяти;

  • значение переменных и др.

Какая информация выводится отладчиком Visual Studio

В заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Читайте также: