Using the Command-Line Analysis Tool


Like the versions of FxCop that preceded Team System, a command-line interface is available for static code analysis. This tool, called FxCopCmd.exe, can be found in your Visual Studio 2005 installation directory under Team Tools\Static Analysis Tools\FxCop.

FxCopCmd can perform any of the code analysis functions that are available to you in the Team System IDE. In fact, the IDE uses FxCopCmd under the covers to execute analysis and generate reports.

FxCopCmd options

The following are some of the options that FxCopCmd.exe supports:

Open table as spreadsheet

Option

Description

/f[ile]: <directory/file>

Assembly file(s) or directory(ies) to analyze. If a directory is used without a filename, Code Analysis will try to analyze all files in that directory with .dll or .exe extensions. You can specify this option more than once. It is required unless you specify a project file with the /project option.

/r[ule]:<directory/file>

A rule assembly file or a directory to browse for rule assemblies. If a directory without a filename is supplied, Code Analysis will look for rules in any files with a .dll extension. You can specify this option more than once.

/r[ule]id:<[+|] Category#CheckId>

Enables or disables a specific rule, supplying its Category and CheckId values — for example, /rid: +!Microsoft.Usage#CA2225.

/o[ut]:<file>

Names a file in which the results of the analysis will be stored in XML form. Required unless the /console option is used.

/p[roject]:<file>

Loads a project file that contains the settings for FxCopCmd to use (discussed in the next section). Required if you do not use both the /file and /rules options.

/t[ypes]:<type list>

Used to constrain analysis to only the specified type(s). Supply a list of comma-delimited type names. Wildcards can be used to specify multiple types. Optional.

/i[mport]:<directory/file>

Loads analysis reports or project files to exclude items from the current test that appear as excluded in the imported file. You may specify a file or a directory. If a directory is specified, Code Analysis will attempt to load all files with an .xml extension. Optional.

/s[ummary]

Displays a summary after analysis. Optional.

/v[erbose]

Gives more detailed status output. Optional.

/q[uiet]

Suppresses output of status details. Optional.

/u[pdate]

Saves the results of the current analysis to the specified project file. Ignored if you do not supply the /project option. Optional.

/c[onsole]

Uses the console to display the analysis results. This is required unless you have specified the /out option.

/c[onsole]xsl:<file>

Applies an XSL file to transform XML output before displaying.

/plat[form]:<directory>

Location of platform assemblies. Optional.

/d[irectory]: <directory>

Location to search for assembly dependencies. Optional.

/help (or) /?

Help about command-line options.

Notice that most of the commands have long and short forms available. For example /summary and /s are equivalent. Arguments support using wildcards (*) to specify multiple items. Arguments with spaces in them must be surrounded with double quotes.

For example, to conduct analysis of a single assembly CustomLibrary.dll, use the following command:

     FxCopCmd /f:CustomLibrary.dll /o:"FxCop Results.xml" /s 

The /f (or /file) argument indicates which assembly to analyze and the /o (or /output) option indicates that analysis output should be stored as XML in FxCop Results.xml. Finally, the /s (or /summary) option will display a short summary of the results of the analysis.

FxCopCmd project files

FxCopCmd's command-line options offer a good deal of flexibility, but to fine-tune your analysis, you should consider using a project file. A project file enables you to set options such as targets and rule assemblies, exclusions, and output preferences. You can then simply use the /project option to tell FxCopCmd to use those settings instead of supplying a detailed list of arguments.

We recommend you create a default FxCopCmd project file that you can copy and customize for each project. Create a new file named EmptyCodeAnalysisProject.fxcop and enter the contents as follows:

      <?xml version="1.0" encoding="UTF-8"?>      <FxCopProject Version="8" Name="Temporary FxCop Project">              <ProjectOptions>                      <SharedProject>False</SharedProject>                      <CompressProjectFile DefaultTargetCheck="True" DefaultRuleCheck=      "True">True</CompressProjectFile>                      <PermitAnalysis>True</PermitAnalysis>              </ProjectOptions>              <Targets>              <Target Name="$(TargetFile)" Analyze="True" AnalyzeAllChildren="True" />              </Targets>              <RuleFiles>              </RuleFiles>              <FxCopReport Version="8" LastAnalysis="2004-04-20 22:08:53Z">              </FxCopReport>      </FxCopProject>

Copy this to a new file and add your project's settings. The rules and files specified in your project file serve as the basis for FxCopCmd execution. Additional rules and target files can be specified on the command line with the /rules and /file options.

For example, here is a simple project file that specifies a target assembly, SampleLibrary.dll, and includes one rule assembly, the default Code Analysis naming conventions assembly:

     <?xml version="1.0" encoding="UTF-8"?>     <FxCopProject Version="8" Name="Sample Library Code Analysis Project">             <ProjectOptions>                     <SharedProject>False</SharedProject>                     <CompressProjectFile DefaultTargetCheck="True" DefaultRuleCheck=                     "True">True</CompressProjectFile>                     <PermitAnalysis>True</PermitAnalysis>             </ProjectOptions>             <Targets>                    <Target Name="C:\SampleLibrary\bin\Debug\SampleLibrary.dll"     Analyze="True"                    AnalyzeAllChildren="True" />             </Targets>             <RuleFiles>                     <RuleFile Name="$(FxCopDir)\Rules\NamingRules.dll" Enabled="True"                     AllRulesEnabled="True" />             </RuleFiles>             <FxCopReport Version="8" LastAnalysis="2004-04-20 22:08:53Z">             </FxCopReport>     </FxCopProject>

Save the above to a file named SampleLibrary.fxcop. To execute Code Analysis for SampleLibrary using this project file, use the following command:

     FxCopCmd /p:SampleLibrary.fxcop /o:"FxCop Results.xml" /s

Build process code analysis integration

You have now seen how to use FxCopCmd from the command line to analyze your code and report potential defects. However, with the full integration of code analysis with the Team System IDE, why would you need to use FxCopCmd?

One of the main reasons is for automated batch operations. A common use of FxCopCmd is to enable automated code analysis from a build process. You can do this with Team System's Team Build, Visual Studio 2005's MSBuild, or one of many other build automation packages available, such as NAnt.

Whichever package you use for your periodic builds, the same basic flow will apply:

  1. Build the assemblies you wish to analyze (e.g., by invoking the C# or VB.Net compilers).

  2. Call FxCopCmd.exe, specifying the /f[ile] option pointing to your freshly built assemblies.

  3. If FxCopCmd outputs any notices of violations, configure your build to stop and display appropriate messages.

  4. Review the reasons for the build failure.

  5. If any of the rules are false positives that can be safely ignored, update your Code Analysis project file to exclude them. Save your project file and rebuild.

  6. If there are any remaining warnings, make the appropriate code changes to comply with the rules.

With Team Build, you can easily enable managed code analysis. Open a build configuration by choosing Team image from book Team Project Settings, and then click Build Configurations. Open Build Steps and check the Perform Static Analysis option. The next time your build runs, a post-build step will invoke the Code Analysis tool and include the results with the build report.

By integrating Code Analysis with your builds, you can ensure that your entire team's work is being evaluated against a consistent set of rules. You will quickly discover when a developer has added nonstandard code. Developers will quickly learn those rules and practices because they don't want to be the person responsible for "breaking the build."



Professional Visual Studio 2005 Team System
Professional Visual Studio 2005 Team System (Programmer to Programmer)
ISBN: 0764584367
EAN: 2147483647
Year: N/A
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net