A set of tools for code and performance analysis is essential for developers who need to develop reliable and robust software. These tools should be capable of detecting errors and defects in coding and performance issues so they're corrected at an earlier stage in development. This is essential to reduce the overall cost of developing applications.
In earlier versions of Visual Studio, there were no analysis tools available. Developers had to depend on third-party tools, create their own custom analysis tools, or ship code without analysis. This is overcome in Visual Studio Team System. With the integration of analysis tools in the Visual Studio environment, it's possible to work efficiently in building applications.
The analysis tools in Visual Studio 2005 Team System can be categorized into two types: Code Analysis Tools and Performance Analysis Tools. These tools are integrated in the Visual Studio environment itself. If needed, you can also use these tools from the command line.
Visual Studio 2005 Team System has two tools for code analysis. PREfast is a tool used for static analysis. It analyzes code written in C or C++ and gives you defects that are likely to appear in the code.
Some defects that could be indicated by using PREfast include null pointer reference, memory leaks, resource leaks, uninitialized memory, and buffer overrun. This tool is integrated in Visual Studio 2005 Team System, and you can enable or disable it as you wish.
You can access this from the property pages of the project. If you enable PREfast and there's any error detected, it appears in the Error list. If you double-click the warning given by PREfast in the error list, it takes you to the actual code that causes the error in the code editor.
// Treat specific warning as error
#pragma warning (error: 6260)
// This warning will now cause compilation to fail// Disable or ignore specific warning
#pragma warning (disable: 6011)
// This warning will be suppressedPREfast also supports annotation where you can get information on conditions before function parameters are used and after function parameters are used. You can also get information on return types. You can use the PREfast tool in the command line as well.
The tool FxCop is used to analyze code for violations in design rules and programming. It also gives you information on assemblies. The violations of design and programming rules are compared to the rules given in the Design Guidelines of Microsoft .NET Framework.
You can refer to these guidelines on the MSDN website. If possible, this tool also gives information on how to fix the violation found by FxCop. Since the tool is integrated with Visual Studio 2005 Team System, you can access this tool from the Property Pages of the project.
You can select the configuration properties and then select the Rules option to enable different types of Rules. You can select Rules like ComRules, NamingRules, and SecurityRules using the checkboxes available for that purpose.
You can set whether you want those Rules to be treated as Errors or Warnings when violated. When the project is built, rule violations are reported in the Error List as Warnings or Errors as selected by you. You can navigate to the exact code of violation by double-clicking the Warning or Error in the Error List.
Performance-related problems in code are identified using the Performance Tools available in Visual Studio 2005 Team System. These tools allow you to measure and evaluate issues related to performance. Two types of profiling are done with these performance tools: Sampling and Instrumentation.
Data is collected periodically by interrupting the application in the sampling method. The data collected is used to create a report file which can be analyzed later using the features available for reporting. The data in sampling method is collected after the application exits.
One advantage of using the sampling method is that the application is interrupted only periodically. One drawback of this method is that you get information based on random sampling.
// Tools -> Performance Tools -> Performance Wizard
// Select "Sampling" option
//
// Sampling collects data at intervals:
// - Low overhead
// - Good for CPU-bound applications
// - May miss short-running methods
//
// Configure sampling interval if needed
// Default: Every 10,000,000 clock cyclesInstrumentation is a method that gets data for a section of the application. Probes are inserted which signal the start and stop of collecting data. The data collected is stored for later analysis. Users can get the exact data used during execution.
// Tools -> Performance Tools -> Performance Wizard
// Select "Instrumentation" option
//
// Instrumentation provides:
// - Exact function call counts
// - Precise timing data
// - Entry/exit tracking
// - Higher overhead than sampling
//
// Best for detailed analysis of specific methodsUsing the Performance Session Wizard available in Visual Studio 2005 Team System, you can create profiling for applications. You can begin with sampling and then, based on the results of sampling, use instrumentation for a specific portion of the application.
The profiling environment can be set up using the Performance Session Wizard. Support for ASP.NET, EXE, and DLL applications is provided by the wizard. You can go to Tools, Performance Tools, Performance Wizard to start a new Performance Session. You can also use the New Performance Session option to create it manually.
You can use the Performance Explorer to get more information about the Performance Session. Performance Reports are automatically added to the Reports node in the Performance Explorer after the application has finished running.
Different types of views are available for viewing the reports. Summary, Functions, Caller/Callee, CallStack, and Type are the views available for reports.
The Summary view is used as the starting point of analysis. The Functions view gives the functions that were executed when the application was run. The functions displayed depend on the method of profiling used. To get information on the functions listed, you need to use the Caller/Callee view.
Performance Report Views:
1. Summary View
- Overview of performance data
- Hot path (most expensive call path)
- Top functions by individual work
2. Functions View
- All functions executed
- Inclusive/exclusive time
- Number of calls
3. Caller/Callee View
- Functions that called selected function
- Functions called by selected function
4. Call Tree View
- Hierarchical execution paths
- Helps identify call chains
5. Modules View
- Performance data by assembly/DLLFor more information on the tools used for code analysis and performance analysis, you can always refer to the MSDN website. These tools are essential for building reliable and robust applications.
Start with sampling to identify performance hotspots, then use instrumentation to analyze specific problem areas in detail. Enable code analysis early in development to catch defects before they become expensive to fix. Use the command-line tools for continuous integration to maintain code quality automatically.
PREfast analyzes C/C++ code for defects like null pointer references and memory leaks through static analysis. FxCop analyzes managed code for violations in design and programming rules based on .NET Framework guidelines. Use PREfast for native code and FxCop for .NET assemblies.
Use sampling for initial performance analysis with minimal overhead, as it periodically interrupts the application. Use instrumentation when you need exact data for specific sections, as it inserts probes to track precise execution details but with more overhead.
Yes, both PREfast and FxCop can be run from the command line, allowing integration into automated build processes. This enables continuous code quality checks without opening Visual Studio.