Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Choosing the Instrumentation Folder

If you want to collect code coverage data while you test code in an assembly, Visual Studio must first instrument that assembly. The instrumentation process adds code to the assembly that generates code coverage data.

You can decide in which folder the assemblies are instrumented. Visual Studio can instrument assemblies in one of two locations:

  • In place. If you select in-place instrumentation, Visual Studio instruments the assembly in the folder where the assembly resides before you run the test. If the assembly is part of an application that you are creating, this is the folder where Visual Studio built the assembly.

  • In the deployment folder. If you do not select in-place instrumentation, Visual Studio instruments the assembly in the deployment folder. Deployment folders are created specifically for test runs. For more information about how to configure test deployment, see How to: Configure Test Deployment.

Choosing between in place and in the deployment folder depends on the level of access you have to the assembly and on the type of the assembly.

Assemblies with limited availability. Any assembly in one or more of the following states is referred to in the following table as an assembly with limited availability:

  • The assembly is shared among multiple people. The problem with shared assemblies is the possibility of conflict between multiple users. An example would be if two users start test runs and also request code coverage data from the same assembly at the same time.

  • The assembly is on a network share, not on your local computer.

  • You have read-only access to the assembly.

Assemblies with a fixed load location. The test execution engine can load certain assemblies only from a specific location. Such an assembly is referred to in the following table as an assembly with a fixed load location. These include the following types of files:

  • COM components

  • Control Panel pages

The following table provides guidance for choosing the correct instrumentation folder. See the Additional notes column for cases that have special factors to consider.

Load location of assembly

Assembly availability

Instrument in this folder

Additional notes

fixed

not limited

in place

(none)

not fixed

limited

in the deployment folder

(none)

not fixed

not limited

Both folders work, but it is recommended that you choose 'in the deployment folder'.

If, after choosing in-place instrumentation, you re-build an instrumented assembly during the test run, the test engine detects that the re-built assembly is newer, does not restore its pre-instrumented version, and generates a run-level warning.

fixed

limited

In place, but see Additional notes

If you do not choose in-place instrumentation, any assembly in a fixed location is not instrumented. This means that, although test execution succeeds and no run-level warning is generated, code-coverage data is not collected.

You can choose between instrumenting in place and in the deployment folder in two ways:

  • To make your choice the default setting, go to the Options dialog box on the Tools menu of Visual Studio. To find this setting, look on the Test Execution page under the Test Tools node.

  • You can also specify the instrumentation folder for your test settings when you configure the diagnostic data adapter for code coverage. For more information, see How to: Configure Code Coverage Using Test Settings for Automated Tests.

To modify the assembly that is to be instrumented in-place, the following criteria must be met:

  • The assembly file must not have the read-only attribute set. You can correct this setting if you have sufficient permissions on the file.

  • The user who runs the test must have the required privileges to modify the assemblies. Because instrumentation is performed by the host application, the account that needs those privileges is the account under which devenv.exe or MSTest.exe is being executed, regardless of local or remote execution. This account belongs to the person who is running Visual Studio, who has executed the MSTest.exe command, or who has started a build which, in turn, is running tests.

  • The assembly file must not be in use or locked by another program. To correct this, you must either end the locking program or wait until it finishes.

If the test engine still cannot instrument one or more assemblies, it generates a run-level warning.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2015 Microsoft