Overview of legacy analysis for managed code in Visual Studio
Applies to: 
Visual Studio 
Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
Visual Studio can perform code analysis of managed code in two ways: with legacy analysis, also known as FxCop static analysis of managed assemblies, and with the more modern .NET Compiler Platform-based code analyzers. This topic covers legacy analysis. To learn more about .NET Compiler Platform-based code analysis, see Overview of .NET Compiler Platform-based analyzers.
Code analysis for managed code analyzes managed assemblies and reports information about the assemblies, such as violations of the programming and design rules set forth in the .NET Design Guidelines.
The analysis tool represents the checks it performs during an analysis as warning messages. Warning messages identify any relevant programming and design issues and, when it is possible, supply information about how to fix the problem.
Note
Legacy analysis (static code analysis) is not supported for .NET Core and .NET Standard projects in Visual Studio. If you run code analysis on a .NET Core or .NET Standard project as part of msbuild, you'll see an error similar to error : CA0055 : Could not identify platform for <your.dll>. To analyze code in .NET Core or .NET Standard projects, use code analyzers instead.
IDE (integrated development environment) integration
You can run code analysis on your project manually or automatically.
To run code analysis each time that you build a project, select the option on the project's Code Analysis property page. For more information, see How to: Enable and Disable Automatic Code Analysis.
To run code analysis manually on a project, from the menu bar choose Analyze > Run Code Analysis > Run Code Analysis on <project>.
Rule sets
Code analysis rules for managed code are grouped into rule sets. You can use one of the Microsoft standard rule sets, or you can create a custom rule set to fulfill a specific need.
Suppress warnings
Frequently, it is useful to indicate that a warning is non-applicable. This informs the developer, and other people who might review the code later, that a warning was investigated and then either suppressed or ignored.
In-source suppression of warnings is implemented through custom attributes. To suppress a warning, add the attribute SuppressMessage to the source code as shown in the following example:
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1039:ListsAreStrongTyped")]
Public class MyClass
{
// code
}
For more information, see Suppress warnings.
Note
If you migrate a project to Visual Studio 2017, you might suddenly be faced with a large number of code analysis warnings. If you aren't ready to fix the warnings, you can suppress all of them by choosing Analyze > Run Code Analysis and Suppress Active Issues.
Run code analysis as part of check-in policy
As an organization, you might want to require that all check-ins satisfy certain policies. In particular, you want to make sure that you follow these policies:
There are no build errors in code being checked in.
Code analysis is run as part of the most recent build.
You can accomplish this by specifying check-in policies. For more information, see Enhancing Code Quality with Project Check-in Policies.
Team build integration
You can use the integrated features of the build system to run the analysis tool as part of the build process. For more information, see Azure Pipelines.