Skip to content

Visual Studio 2005 Team System: Building Robust and Reliable Software

August 10, 2009

In Visual Studio 2005 Team System, developers can conduct static analysis and dynamic analysis of their code by using Code Analysis and Performance Tools.

Code Analysis Tools

The goal of the Code Analysis Tools is to make it possible for developers to use static analysis on their projects to detect and correct code defects. To achieve this goal, Visual Studio 2005 Team System includes two tools:

  • PREfast
  • FxCop


Prefast is a static analysis tool that provides information to developers about possible defects in their C/C++ source code. Common coding errors reported by Prefast include buffer overrun, un-initialized memory, null pointer dereference, memory and resource leaks.


FxCop is a static analysis tool that analyzes managed code assemblies and reports information about the assemblies, such as violations of the programming and design rules set forth in the Microsoft .NET Framework Design Guidelines. FxCop represents the checks it performs during an analysis as rules. A rule is managed code that analyzes an assembly and returns a message about its findings. Rule messages identify any relevant programming and design issues and, when possible, supply information on how to fix the target.

IDE Integration

To make it natural for developers to use analysis tools, developers can select Run FxCop on the project’s Property Pages, as shown in Figure 3.

Figure 3. Enabe FxCop

Additional options for including or excluding rules and treating rules as warnings or errors can also be accessed from Property Pages, as shown in Figure 4.

Figure 4. FxCop Rules

Once FxCop is enabled, during the build process, FxCop reports rule violations in the Error List, as shown in Figure 5.

Figure 5. FxCop Rule Violation

The Error List provides information about the rule violation and suggestions to correct the problem. You can easily navigate to the offending line of code by simply double-clicking a rule violation in the Error List.

One Comment leave one →
  1. August 10, 2009 3:56 pm

    Software development organizations are increasingly using static analysis as part of their acceptance criteria for check-in, particularly for Agile environments. One of the common desires out of an Agile process is to have good, working code every day in the main branch. Allowing developers to fix problems while they are developing and before they check-in just means better written, higher quality code gets checked-in. You get an extra bonus if you are using one of those static analysis tools that do interprocedural analysis because then you can address some integration problems much faster. Better quality software earlier just means more cycle times and lower risk.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: