Instrumenting and Re-Signing Assemblies

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

But if the assembly you are testing was signed with a strong name, the code modification caused by instrumentation invalidates its signing. So Visual Studio automatically tries to re-sign the assembly immediately after the instrumentation step.

If the re-signing succeeds, the test run will finish and produce results correctly. If the signing is unsuccessful, an error such as the following is generated:

Strong name verification failed for the instrumented assembly 'SignedLibrary, Version=, Culture=neutral, PublicKeyToken=1696e096eba75082'. Please make sure that the correct key file for re-signing after instrumentation is specified in the test settings.

To fix this error, try the following:

  • Re-sign the assembly. If you have the key file that was used for signing the assembly, you can supply it so that Visual Studio can automatically re-sign the assembly.

  • Disable Signing Verification. You can disable the verification of signing on the computer on which you are testing the assembly. This action applies only to assemblies you specify.

Re-sign the Assembly

In your test settings for the diagnostic data adapter for code coverage, you can specify a key file for re-signing binaries after instrumentation. If you are testing multiple assemblies that have been signed, Visual Studio will try to re-sign all the strong-named assemblies that were signed with the key file that you specify.

Specifying a key file adds a re-signing step to the test run process. Visual Studio will automatically determine which assemblies must be re-signed by using the key file that you specified. All the assemblies that can be re-signed by using that key file will be re-signed.


Assemblies can be re-signed only by using a key file, not a key name.

Re-signing assemblies occurs incompletely or not at all in the following cases:

  • If the key file is not available, Visual Studio cannot re-sign the assembly. You can try to re-generate the key file and then try again to re-sign the assembly.

  • If the key file is password protected, re-signing will fail.

  • Only one key file is supported per test run. For example, consider a test run that references several assemblies. Some of these assemblies were signed using one key file, and others were signed using a different key file. Because you can select only one key file, the assemblies that need the other key file will not be re-signed, and would have to be re-signed manually. If some assemblies are left unsigned, an error at the test-run level is generated. In this case, you might want to disable signing verification, as described in Disable Signing Verification.

Disable Signing Verification

If re-signing fails, you can select to disable signing verification for this assembly, for the duration of your test run. For example, the re-signing will fail if the correct key file is not available. To disable signing verification, use the Sn.exe (Strong Name Tool) with the –Vr option, as shown here:

SN -Vr <assembly name>

This disables strong-name verification, for the specified assembly only, on the computer on which you run the command.

You can do this only if you have sufficient permissions.

After the test run has completed, re-enable signing verification. To do this, use the SN.exe command by using the –Vu option, as shown here:

SN -Vu <assembly name>


It is important that you re-enable signing verification. If signing verification remains disabled, it can cause security problems.

See Also


How to: Configure Code Coverage Using Test Settings for Automated Tests

How to: Obtain Code Coverage Data

Create Test Settings to Run Automated Tests from Visual Studio

Create Test Settings for Automated Tests as Part of a Test Plan

How to: Sign an Assembly with a Strong Name


Sn.exe (Strong Name Tool)


Strong-Named Assemblies