In addition to using PVS-Studio directly from Visual Studio, you can also run analysis of MSBuild (i.e. Visual C++ and Visual C#) projects from the command line. This can be useful for setting up regular automatic analyzer runs. For example, during the "night builds" on the build server.
To analyze C++/C# projects or solutions (sln) files that contain such projects, you can use the command line version of the PVS-Studio analyzer directly without having to start the IDE (devenv.exe) process and open in it projects that you are intending to check.
The 'PVS-Studio_Cmd.exe' tool can be found in PVS-Studio installation directory (default path is ' c:\Program Files (x86)\PVS-Studio\'). The '--help' command displays all available arguments of cmd analyzer:
The main arguments of the analyzer:
Here is an example of running the analysis for Visual Studio solution "My Solution":
PVS-Studio_Cmd.exe --target "mysolution.sln" --platform "Any CPU" --configuration "Release" --output "mylog.plog" --settings "pvs.xml" --progress
The command line version of the PVS-Studio analyzer supports all settings on filtering/disabling messages available in the IDE plugin for Visual Studio. You can either set them manually in the xml file, that is passed through the '--settings' argument, or use the settings specified through the UI plugin, without passing this argument. Note that the IDE plug-in of PVS-Studio uses an individual set of settings for each user in the system.
If you've installed several PVS-Studio instances of different versions for the current system user, all program instances will use the installation directory, specified during the last installation. To avoid conflicts in the analyzer working process, in the settings, passed with the argument --settings (-s), you have to specify the path to the installation directory (the value of the <InstallDir> element).
PVS-Studio_Cmd allows you to analyze individual files specified in a list, a path to which can be passed to the analyzer with the --sourceFiles (-f) flag. This file list should be in XML format and it can contain a list of absolute paths to the source files and\or a list of file masks that define such source file paths.
<SourceFilesFilters> <SourceFiles> <Path>C:\Projects\Project1\source1.cpp</Path> <Path>C:\Projects\Project1\source1.h</Path> <Path>\Project2\source2.cpp</Path> <Path>source_*.cpp</Path> <Path>stdAfx.h</Path> </SourceFiles> <TlogDirs> <Dir>D:\Build\Tlogs\</Dir> </TlogDirs> <SourcesRoot>C:\Projects\</SourcesRoot> </SourceFilesFilters>
Let us review in detail all of available fields and their possible values.
When running analysis with the --sourceFiles (-f) flag, the analyzer, contrary to the 'normal' run on the whole project\solution, will generate its warning messages only for the files that are explicitly specified through the SourceFiles filters. This means that when analyzing a source cpp file, the analyzer will only generate messages for this file alone - the messages on the header (h/hpp) files that are included into this source file will be filtered out, unless these header files are also explicitly specified by the SourceFiles filters.
The PVS-Studio_Cmd utility defines several non-zero exit codes, which do not necessarily indicate some issue with the operation of the tool itself, i.e. even when the tool returns something other when zero it does not always mean that the tool has 'crashed'. The exit code is a bit mask that represents all states that occurred during the PVS-Studio_Cmd utility operation. For example, the tool will return non-zero code (it will be 256 actually) when the analyzer finds some potential issues in the code being analyzed. Such behavior allows you to handle this situation individually, for example, when the policy of using the analyzer on a build server does not allow analyzer issues to be present in the code that was committed to a revision control system. Consider another example: during analysis there were found some issues in code, and one of the source files is missing on disk. In this case the exit code of the PVS-Studio_Cmd utility will be 264 (8 - some of the analyzed source files or project files were not found, 256 - some issues were found in the source code), or, in binary representation 100001000.
Next, let's examine all possible PVS-Studio_Cmd state codes that form a bit mask exit code.
Let us provide an example of a Windows batch script that decodes the PVS-Studio_Cmd utility exit code:
@echo off "C:\Program Files (x86)\PVS-Studio\PVS-Studio_Cmd.exe" -t "YourSolution.sln" -o "YourSolution.plog" set /A FilesFail = "(%errorlevel% & 1) / 1" set /A GeneralExeption = "(%errorlevel% & 2) / 2" set /A IncorrectArguments = "(%errorlevel% & 4) / 4" set /A FileNotFound = "(%errorlevel% & 8) / 8" set /A IncorrectCfg = "(%errorlevel% & 16) / 16" set /A InvalidSolution = "(%errorlevel% & 32) / 32" set /A IncorrectExtension = "(%errorlevel% & 64) / 64" set /A IncorrectLicense = "(%errorlevel% & 128) / 128" set /A AnalysisDiff = "(%errorlevel% & 256) / 256" set /A SuppressFail = "(%errorlevel% & 512) / 512" set /A LicenseRenewal = "(%errorlevel% & 1024) / 1024" if %FilesFail% == 1 echo FilesFail if %GeneralExeption% == 1 echo GeneralExeption if %IncorrectArguments% == 1 echo IncorrectArguments if %FileNotFound% == 1 echo FileNotFound if %IncorrectCfg% == 1 echo IncorrectConfiguration if %InvalidSolution% == 1 echo IncorrectCfg if %IncorrectExtension% == 1 echo IncorrectExtension if %IncorrectLicense% == 1 echo IncorrectLicense if %AnalysisDiff% == 1 echo AnalysisDiff if %SuppressFail% == 1 echo SuppressFail if %LicenseRenewal% == 1 echo LicenseRenewal
If your C/C++ project doesn't use Visual Studio's standard build system (MSBuild) or even uses a custom build system \ make files through Visual Studio NMake projects, you won't be able to analyze this project with the PVS-Studio_Cmd.
If this is the case, you can use the compiler monitoring system that allows you to analyze projects regardless of the build systems they use by "intercepting" compilation process invocations. The compilation monitoring system can be used both from the command line and through the C and C++ Compiler Monitoring UI client (Standalone.exe).
You can also integrate the invocation of command line analyzer kernel directly into your build system. Notice that this will require you to define the PVS-Studio.exe analyzer kernel call for each file to be compiled, just like in the case when calling the C++ compiler.
When running project analysis from the command line, by default, the same settings are used as in the case when it is run from the IDE (Visual Studio). The number of processor cores to be used for analysis depends on the number specified in the analyzer settings. You can also specify the settings file directly with '--settings' argument, as was described above.
As for the filtering systems (Keyword Message Filtering and Detectable Errors), they will not be used when running the analysis from the command line. It means you'll see all the messages in the log file anyway, regardless of the parameters you have specified. However, when loading the log file in the IDE, the filters will be applied. This is because filters are applied dynamically to the results (including the case when you analyze your project from the IDE as well). It's very convenient since you may want to switch off some of the messages you've got (for example V201). You only need to disable them in the settings to have the corresponding messages disappear from the list WITHOUT you having to rescan the project.
The plog file format (XML) is not intended for directly displaying to or read by a human. However, if you need to filter off the analysis results and convert them into a "readable" format, you can use the PlogConverter utility available within the PVS-Studio distribution. You can also download the source code of the utility.
PlogConverter allows you to convert one or more plog files into the following formats:
The format of the log file is defined by the command line parameters. You can also use them to filter the results by rule sets, levels, and individual error codes.
Here's an example of the PlogConverter command line launch (in one line):
PlogConverter.exe test1.plog test2.plog -o "C:\Results" -r "C:\Test" -a GA:1,2,3;64:1 -t Html,Txt,Totals -d V101,V105,V122
PlogConverter will be launched for the 'test1.plog' and 'test2.plog' files in the current folder and the error messages from all specified plog files will be merged and saved into the Results folder on disk C; only messages from the General Analysis (GA) rule set of levels 1, 2, and 3, and from the 64-bit diagnostic rule set (64) of level 1 will be used. Diagnostics V101, V105, and V122 will be filtered off from the list. The results will be saved into a text and HTML files as well as a summary text file for all the diagnostics (with the mentioned parameters taken into account). The original plog file will remain unchanged.
Detailed description of the levels of certainty and sets of diagnostic rules is given in the documentation section "Getting Acquainted with the PVS-Studio Static Code Analyzer".
A detailed help on all the parameters of the PlogConverter utility can be accessed by executing the following command:
If you need to convert the plog file into some specific format, you can do it by parsing the file as an XML document yourself.
Note that you can reuse the algorithm of sorting out a structure of a plog file from our utility to create a customized output format of analysis results.
The process of long-term use of the PVS-Studio code analyzer is comprised of two stages: integration and regular use. When integrating PVS-Studio into an existing large-scale project, programmers will usually read the analyzer messages and either fix the code or mark it using the "Mark as False Alarm" and "Message Suppression" features. Having sorted out all the messages, they will then re-analyze the code once again to get 0 warnings (given that the messages marked as false positives or suppressed through suppress files are set to stay hidden). It means that the integration stage is over and the stage of regular use sets in.
From this point on, all the new code added into the project will be analyzed by PVS-Studio. Actually, the ENTIRE code base will be analyzed, but you'll be seeing only new messages. Errors will be found in freshly written/fixed code or old code that has been left unmarked.
The option of running the analysis from the command line is useful when developers need to launch it regularly (daily, for instance). The procedure looks as follows:
This way, regularly running PVS-Studio on your project will help you avoid new bugs in the code.
To install the PVS-Studio distribution from the command line in a "quiet" mode (i.e. without displaying the UI and dialog boxes), you need to pass the following parameters into it (in one line):
PVS-Studio_setup.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /COMPONENTS=Core,Standalone,MSVS,MSVS\2010, MSVS\2012,MSVS\2013,MSVS\2015,MSVS\2017,MSVS\2019
The /COMPONENTS argument allows specifying the components to be installed: Standalone (C and C++ Compiler Monitoring), plugins for different IDEs and is optional.
PVS-Studio may require a reboot if, for example, files that require update are locked. To install PVS-Studio without reboot, use the 'NORESTART' flag. Please also note that if PVS-Studio installer is started in a silent mode, the computer may be rebooted without any warnings or dialogs.
Keep in mind that it is required to avoid running Visual Studio (the devenv.exe process) while installing PVS-Studio.
The PVS-Studio-Updater.exe utility can check for analyzer updates and download and install them on a local machine. To run the update utility in the 'quiet' mode, you can use the same parameters as for the distribution installation process:
PVS-Studio-Updater.exe /VERYSILENT /SUPPRESSMSGBOXES
If there are no updates available on the server, the utility will terminate with '0' exit code. Since PVS-Studio-Updater.exe performs local installation, you must avoid running the devenv.exe process while it is working as well.
Running PVS-Studio daily from the command line can help you significantly increase the quality of your code. Sticking with this approach, you will get 0 diagnostic messages every day if your code is correct. And should there be any incorrect edits of the old (already scanned and fixed) code, the next run of PVS-Studio will reveal any fresh defects. Newly written code will be regularly scanned in automatic mode (i.e. independently of the programmer).