﻿# Использование PVS\-Studio в очень больших проектах \(интеграция с MSBuild\)

Если в ваше решение \(solution\) входит много больших проектов, то работа с анализатором PVS\-Studio может стать некомфортной\. В этой небольшой заметке мы рассмотрим, почему это происходит и как можно исправить ситуацию, интегрировав PVS\-Studio в сборочный процесс MSBuild\.

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

Но будем считать, что у вас именно тот самый случай\. В solution включено большое количество проектов\. Общее количество компилируемых файлов исчисляется многими тысячами\.

Анализатор PVS\-Studio использует функции API, предоставляемые Visual Studio, чтобы собрать информацию о файлах\. Он должен узнать, какие файлы следует проверять, какие директивы препроцессора заданы для каждого файла, какие директории с заголовочными файлами нужно использовать и так далее\. 

Если проектов и файлов много, то сбор информации начинает занимать существенное время\. PVS\-Studio надолго задумывается перед началом анализа файлов\. Особенно это заметно при использовании  инкрементального анализа\. Часто получается, что сбор информации идёт в несколько раз дольше, чем сам анализ нескольких изменившихся файлов\.

Сделать с этим мы ничего не можем, так как не можем ускорить вызовы API функций\. Однако существует обходной путь\. Это интеграция со сборочным процессом MSBuild\.

В этой заметке мы не будем рассматривать, как начать использовать MSBuild\. Это очень подробно описано в документации\. Нет смысла копировать оттуда текст\. Со временем что\-то может измениться и заметка в блоге устареет\. Поэтому отсылаем читателя за более подробной информацией к разделу в документации: "[Прямая интеграция анализа PVS\-Studio в сборочный процесс MSBuild\. Режим интеграции MSBuild в Visual Studio IDE](https://pvs-studio.ru/ru/docs/manual/0028/)"\.

Здесь же отметим только достоинства и недоставки интеграции\.

Достоинства:

1\) Анализатору не нужно собирать информацию о файлах\. Всю необходимую информацию ему сообщает MSBuild\. Это может существенно сократить  время анализа в проектах с огромным количеством файлов\.

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

3\) Можно проверить проекты, которые являются расширением стандартной проектной модели Visual C\+\+\. Например, проекты драйверов\. Любой пользователь Visual C\+\+ может расширить проектную модель для добавления каких\-нибудь своих специфичных параметров сборки\. Но, если проект собирается через MSBuild, в него может быть встроена проверка PVS\-Studio\. Обычная же проверка PVS\-Studio через плагин не всегда в описанной ситуации отработает, так как такая расширенная проектная модель не будет отображена в Visual Studio Extensibility API\.

4\) Так как проверка  PVS\-Studio интегрирована в сборочный процесс, то проект можно проверять \(одновременно со сборкой\) на системе без установленной IDE, например, на сборочном сервере во время ночной сборки\.

Недостатки:

1\) Поскольку запуск анализатора выполняет MSBuild, то получается, что он начинает отвечать за распараллеливание\. MSBuild производит распараллеливание сборки на уровне проектов\. Для каждого проекта запускается отдельный экземпляр MSBuild, а он в свою очередь запускает отдельный экземпляр PVS\-Studio\. Недостаток состоит в том, что нельзя выполнить параллельный анализ файлов в рамках одного проекта\.

2\) Интеграция с MSBuild приведёт к необходимости модификации проектного файла \(\*\.vcxproj\)\.