Two Approaches

TFS uses MSBuild (branded as Team Foundation Build) to compile projects. The challenge is to pass in the appropriate parameters since TFS2010 now exclusively utilizes the XAML windows workflow to define the build. You will have to edit the XAML template. Once you have located and opened the XAML build template, you can include the parameters for NCover in several ways. Two solid approaches are presented here.

Code the build workflow.

Enter all the necessary processes, variables, and arguments into the XAML TFS workflow. Users may want to try a simplified version of a workflow invocation before changing their build configurations. This makes it easier to test before being included into a large build process. There are several parts to a simplified NCover call:

1. Determine how you want to run coverage. This will depend on what your team setup is like, how many projects you have, how often you want to build / test / profile your code, etc. But once you know, you can create an NCover sequence to fit into the XAML build process.
2. Enter the NCover sequence. Find the place(s) in the build flow that you'd like NCover to run. Then you can drag and drop in a sequence and title it. Next you will drop two invokeProcess activities in the sequence. The first will invoke NCover Console, which should be installed on your server, and then second NCover Reporting. The rest of the work involves making sure that all the variables (such as file paths, log reports, coverage files) are all arranged in the way that suits your needs.
3. Set up the appropriate file paths, etc. Here come the variables -- coverage file paths, ncover.console arguments, ncover.reporting arguments, and etc -- that will be passed to the two processes. Keep in mind that you will also want to consider how you'd like coverage to be reported / stored on the server. If you'd like it to become part of source, you can set a file path to include it in your repo. Otherwise, you can output to the build server. For the NCover.Console.exe process, a variable that lists (as a string) the arguments for the app as well as the file path on the build server for the app must be passed in. The same goes for NCover.Reporting.exe: all arguments, file paths, etc should be specified in variables and passed into to the process.
4. Test, recheck, refine. Once the processes are defined and variables set, try queuing a simple build and ensure that NCover is being run properly on the server. Check also that the artifacts from the profiling session are being output the appropriate folder specified at the beginning of the setup. If you created the simplified workflow case for running NCover, just copy it into your overall build workflow and test again. Happy coding!

Advantages: Easier to maintain in the TFS interface. No need to edit any other kind of script. using only XAML. Reusable anywhere in the XAML flow for subsequent build / test sequences.

Disadvantages: It can be difficult for users unfamiliar with XAML and the Microsoft workflow to learn its interface.

Include a .bat Script.

Create a bat script to execute NCover after compiling and include it in source control. There are two parts to this process:

1. Create the Script: First decide what parameters NCover will run with. These are the settings normally included in the text boxes of an NCover project setup. They include such things as the name of the application to profile, the type of coverage needed, an output directory for the coverage xml, and etc. Create a normal console call to NCover and place this call in a .bat script. Save the file and include it into your source control. Once you save the file, you have to tell the XAML template to call the script.
2. Call in Build: The XAML should be checked out for editing and open. Navigate to the place in the build where you would like NCover to run. This could be inside a conditional statement or simply placed directly following the MSBuild invocation. At whatever spot you choose, you will open the tool box and select an “Invoke Process” activity. Drag and drop it into the workflow. Next, you must set the parameters for that activity. These include the bat script, which is the file that is called. Don’t forget that you’re working with VBScripts here, so you will need to include the filename in “” for a string. Once these are set, you can save the workflow and queue a new build.

Advantages: Keeps all NCover execution in one file for efficiency in editing, and avoids unnecessary programming of XAML file.

Disadvantages: An extra file goes into source control and users who modify the build must have knowledge of bat scripting and this file in order to invoke NCover.

In either case, you should see coverage artifacts appear in the drop directory that you have specified for the build. If you wish, you can always change the location of the coverage, and even include it into source. For more tutorials on the windows workflow, see the Microsoft website.