Build definitions replace the build types of Microsoft Visual Studio 2005 Team System. Unlike build types, you can use the Team Explorer user interface to modify build definitions. Build definitions also have workspace support in version control. You can now specify local paths and store the build files in any location you specify in version control. For more information, see How to: Create a Build Definition and Understanding Team Foundation Build Configuration Files.

You can specify a trigger for a build when you create a new build definition or modify an existing one. You can use on-demand builds, rolling builds, and continuous integration where each check-in starts a build. You can also define how long to wait between builds when defining rolling builds. For more information, see How to: Create a Build Definition.

You can now run builds on a schedule, even if there are no changes. For more information, see How to: Create a Build Definition.

Build agents can be named independently of the build computer name. For more information, see How to: Create and Manage Build Agents. Each build agent can connect to a build computer via two ports: an interactive port and the default port used to run builds. For more information, see How to: Configure an Interactive Port for Team Foundation Build.

You can now set up Team Foundation Build to require HTTPS and SSL. For more information, see How to: Set up a Build Agent to Require HTTPS and Secure Sockets Layer (SSL).

Team System 2008 Team Foundation Server includes new properties for customizing builds. These properties include customizing the behavior of C++ builds, SkipInvalidConfigurations, CustomizableOutDir, and CustomizablePublishDir. For more information, see Customizable Team Foundation Build Properties.

Team Foundation Build includes a number of new targets that can be overridden to customize the build process. For more information, see Customizable Team Foundation Build Targets, BuildStep Task, GetBuildProperties Task, SetBuildProperties Task, and WorkspaceItemConverterTask Task.

You can now destroy or permanently delete source-controlled files from Team Foundation version control. For more information, see Destroy Command.

You can now enable Team Foundation version control to retrieve the latest version of a file automatically when you check it out. For more information, see Team Foundation Check-Out Settings.

You can now annotate source code files. You can view line-by-line information in source code about what changes were made, who made the changes, and when the changes were made. For more information, see How to: View File Changes Using Annotate.

You can now compare two server folders, two local folders, or a server folder and a local folder using source control. You can see differences such as missing items, and items that have additions, deletions, or conflicting changes. For more information, see How to: Compare Two Folders.

Code analysis has more than 20 new rules. Several rules have been enhanced by providing greater accuracy, particularly around naming rules.

For more information, see Code Analysis for Managed Code Warnings, Code Analysis for C/C++ Warnings and How to: Enable and Disable Code Analysis for Managed Code.

You can use the spelling checker for resource strings as well as class, method, and property names. You can use a custom dictionary to check non-standard words.

You can suppress code analysis issues from the error window at either the project level or in-source.

You can automatically suppress error messages from generated code. This is particularly useful for designer-generated code.

When you copy the settings from the server to your project, you now have the option to replace your local selection, or merge the policy rules with your local project rules. Also, you now have more complete information about policy violations. This enables you to determine the source of the violation.

The Profiler now includes support for both the 64-bit applications that run on 64-bit operating System and hardware and the 32-bit applications executed on 64-bit operating system and hardware.

The Profiler has full call stacks for allocation. This is useful for allocation that occurs in non-user code, but is indirectly caused by user actions. By using the full stack, you can see exactly which parts of your code are indirectly causing the allocation.

You can collect allocation data by configuring settings in the performance session property page. Use the allocation view in the performance report to see your results.

For more information, see How to: Collect .NET Memory Allocation and Lifetime Data and Allocation View.

Profiling tools now includes an instruction pointer and line views in performance reports. Also, the modules view now includes line information.

For more information, see Instruction Pointer (IP) View, Line View and Modules View.

You can configure performance reports for noise reduction. This limits the amount of data in the Call Tree view and the Allocation view. By using noise reduction, performance problems are more prominent. This is helpful when you analyze performance reports

For more information, see How to: Configure Noise Reduction in Performance Reports, Call Tree View and Allocation View.

Profiling tools includes a runtime control. The runtime control starts automatically with the profiler. It can be paused and resumed for performance data logging. In addition, you can use the runtime control to start the application with logging paused. This enables you to skip data collection on application startup. When you use the runtime control, you can manually insert annotations in the performance data when events of interest occur in the application lifetime. You can filter the data on your annotations later.

You can now filter performance reports on timestamp, process, thread, and marks. You can use the show query button to get the filtered analysis. Also, you can use the /summaryfile option from the VSPerfReport command.

For more information, see VSPerfReport.

The Profiler now supports the comparison of reports. You can compare a report either by using the Performance Explorer or the /diff on options from the VSPerfReport command.

For more information, see Comparing Profiling Tools Data Files, How to: Compare Profiler Data Files and VSPerfReport

Profiling tools provide new friendlier chip-counter names (For example: "L2 Misses", "ITLB Misses", "Mispredicted Branches"). You can modify xml files to further configure counters for a specific architecture.

The Profiler now collects Windows counters (for example, "% Processor Time", "% Disk Time", "Disk Bytes/sec", "Page Faults/sec"). You can use either the windows counters node in the performance sessions properties page or the /wincounter option from the VSPerfCmd command. The marks view displays the counters. You can use counters as filtering endpoints.

For more information, see Marks View, How to: Collect Windows Counter Data and VSPerfCmd.

Profiling tools enable you to generate small compressed report files that open up quickly. This is because these files, which are created from full reports, are analyzed already. You can either right-click the report in the Performance Explorer and choose Save Analyzed or use the /summaryfile option from the VSPerfReport command.

For more information, see How to: Save Analyzed Report Files and VSPerfReport.

Profiler now has the ability to automatically expand the most expensive code path in the call tree and allocation view of the performance report.

For more information, see Call Tree View and Allocation View.

The Profiler includes support for rich reports in the clipboard. You can copy and paste rich data (tables with headers and values) from the performance reports.

Profiling tools now support Windows Communications Foundation (WCF).

You can create performance sessions for Web and Load tests from Test View and Test Results.

Note:
This feature applies only to Visual Studio Team System.

Developers using Visual Studio Professional Edition can now create and run two types of tests: unit and ordered. You can use a unit test to validate that a specific method of production code works correctly, to test for regressions, or to perform buddy testing or smoke testing. Ordered tests run other tests in a specified order. For more information, see Using Testing Tools in Visual Studio Professional Edition.

New menus and key combinations enable developers of unit tests to start test runs and select the tests to run more quickly. Also, you can now generate tests from a binary file, without access to product source code. You can generate tests for generic data types as return values and method parameters. For more information, see How to: Run Selected Tests, How to: Generate a Unit Test, and Unit Tests and Generics.

Test classes can now inherit members from other test classes. This enables developers to create initializations or tests in a base test class, from which all other derived tests classes will inherit. This feature eliminates duplicated test code. This gives developers more options to customize their unit tests correctly. For more information, see Unit Tests Overview.

Visual Studio provides a suite of tools for testing C# and Visual Basic smart device applications. These tools provide a subset of the functionality found in Test Edition. For more information, see Testing Tools for Smart Device Projects.

Typically, you run tests in the default environment provided by the Team System testing tools. To run tests in a different environment, use a host adapter. You can use the Visual Studio SDK to create new host adapters. Download the Visual Studio SDK from the affilliate site.

You can now use a wizard to easily bind a unit test to a data source, including CSV files and XML files. For more information, see How to: Configure a Data-Driven Unit Test.

• You can insert a call to one Web test from a second Web test. For more information, see How to: Insert a Call to Another Web Test.

Test Edition now includes built-in support for csv and xml files. A new wizard facilitates the data binding process. You can also preview the data before you complete the process. For more information, see Data Binding in Web Tests.

Test Edition now includes support for test level validation rules. You can create validation rules at the test level. These new rules can apply to all individual requests in the test. You can stop a Web test if an error occurs in the test. Also, you can validate the return of an expected HTTP status code. For more information, see Using Validation and Extraction Rules.

In Test Edition you can now extract requests from Web tests to create new Web tests. You can also insert calls to other Web tests. This means you can create Web test components and reuse your Web tests and Web requests. For more information, see How to: Extract a Web Test and How to: Insert a Call to Another Web Test.

Load tests now offer additional load-modeling options. These options enable you to create load tests that more accurately model the expected real-world usage of an application or Web site. You can now model usage based on the number of tests run, the amount of time spent on each test, or the pace at which the users run the tests. For more information, see About Test Mix.

Test Edition Load Test Analyzer includes a new summary view that displays the key indicators and results in a single page that you can print and export. Also, four new built-in graphs display key information. You can view up to four graphs at the same time. These enhancements enable you to view up to four tables at the same time. For more information, see the following:

• The Load Test Results Summary

• Working with Load Test Tables

• Working with Load Test Results Graphs

Test Edition includes a new Repository Management dialog box that enables you to access directly the load test results repository. Now it is easy for you to open, import, export, and delete load test results. For more information, see Managing Results in a Repository.

As you work with Test Edition, it creates and stores data in XML files. These files include the following:

• Test metadata file. This type of file has the extension .vsmdi. Test metadata files store information about the tests in your solution. For more information, see Reusing Tests.

• Test results file. This type of file has the extension .trx. When you run tests, Visual Studio automatically saves test results to a .trx file. For more information, see How to: Export Test Results.

• Manual tests in text format. This type of file has the extension .mtx. When you create a manual test in text format, it is saved into your test project as a file of this type. For more information, see How to: Create a Manual Test.

In Team System 2008 Test Edition, all the XML files used by Test Edition are defined by a new XSD named TestTypes.xsd. Any edits that you make to any of these files, manually or programmatically, must result in XML that conforms to the schema defined in this XSD. Similarly, any files that you create with these extensions must also conform to the schema defined in this XSD. Otherwise, Test Edition cannot use them.

Test projects created in Visual Studio 2005 contain XML files. When you open a Visual Studio 2005 test project, the Visual Studio 2008 project upgrade wizard prompts you for permission to convert the files into the new format. To use the files in Team System 2008 Test Edition, you must let Visual Studio convert the files. If you decide not to convert or upgrade one or more files, Visual Studio cannot open your test project. Similarly, if you add an existing file of the previous format to a test project, you will be prompted to let Visual Studio upgrade the file format. If you answer yes, Visual Studio converts the file and makes it available as part of the test project. If you answer no, your request to add the files is canceled.

This release provides the following benefits:

• Improved Web test validation rules.

  You now have more flexibility to apply validation rules and use their results to control Web test program flow.

• Better control of load modeling.

  You now have more flexible ways to control the load modeling in load tests that you run.

• Improved load test analyzer views.

  New built-in graphs and viewing capabilities make it easier for you to quickly understand load test results.

• Improved load test results repository management.

  You now have easier access to the repository for load test results.

• Schematized XML file for test results.

  You can now work programmatically with the test results that are automatically stored in XML format in a .trx (test results) file.

For more information, see What's New in Test Edition.